Root/
| Source at commit 1146 created 12 years 11 months ago. By azimutz, Sync with trunk (r1145). Add nVidia dev id's, 0DF4 for "GeForce GT 450M" (issue 99) and 1251 for "GeForce GTX 560M" (thanks to oSxFr33k for testing). | |
|---|---|
| 1 | /*␊ |
| 2 | * Copyright (c) 1999 Apple Computer, Inc. All rights reserved.␊ |
| 3 | *␊ |
| 4 | * @APPLE_LICENSE_HEADER_START@␊ |
| 5 | * ␊ |
| 6 | * This file contains Original Code and/or Modifications of Original Code␊ |
| 7 | * as defined in and that are subject to the Apple Public Source License␊ |
| 8 | * Version 2.0 (the 'License'). You may not use this file except in␊ |
| 9 | * compliance with the License. Please obtain a copy of the License at␊ |
| 10 | * http://www.opensource.apple.com/apsl/ and read it before using this␊ |
| 11 | * file.␊ |
| 12 | * ␊ |
| 13 | * The Original Code and all software distributed under the License are␊ |
| 14 | * distributed on an 'AS IS' basis, WITHOUT WARRANTY OF ANY KIND, EITHER␊ |
| 15 | * EXPRESS OR IMPLIED, AND APPLE HEREBY DISCLAIMS ALL SUCH WARRANTIES,␊ |
| 16 | * INCLUDING WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY,␊ |
| 17 | * FITNESS FOR A PARTICULAR PURPOSE, QUIET ENJOYMENT OR NON-INFRINGEMENT.␊ |
| 18 | * Please see the License for the specific language governing rights and␊ |
| 19 | * limitations under the License.␊ |
| 20 | * ␊ |
| 21 | * @APPLE_LICENSE_HEADER_END@␊ |
| 22 | */␊ |
| 23 | /*␉$NetBSD: exec.h,v 1.6 1994/10/27 04:16:05 cgd Exp $␉*/␊ |
| 24 | ␊ |
| 25 | /*␊ |
| 26 | * Copyright (c) 1993 Christopher G. Demetriou␊ |
| 27 | * All rights reserved.␊ |
| 28 | *␊ |
| 29 | * Redistribution and use in source and binary forms, with or without␊ |
| 30 | * modification, are permitted provided that the following conditions␊ |
| 31 | * are met:␊ |
| 32 | * 1. Redistributions of source code must retain the above copyright␊ |
| 33 | * notice, this list of conditions and the following disclaimer.␊ |
| 34 | * 2. Redistributions in binary form must reproduce the above copyright␊ |
| 35 | * notice, this list of conditions and the following disclaimer in the␊ |
| 36 | * documentation and/or other materials provided with the distribution.␊ |
| 37 | * 3. The name of the author may not be used to endorse or promote products␊ |
| 38 | * derived from this software without specific prior written permission␊ |
| 39 | *␊ |
| 40 | * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR␊ |
| 41 | * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES␊ |
| 42 | * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.␊ |
| 43 | * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,␊ |
| 44 | * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT␊ |
| 45 | * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,␊ |
| 46 | * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY␊ |
| 47 | * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT␊ |
| 48 | * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF␊ |
| 49 | * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.␊ |
| 50 | */␊ |
| 51 | ␊ |
| 52 | #ifndef _MACHO_RELOC_H_␊ |
| 53 | #define _MACHO_RELOC_H_␊ |
| 54 | #include <stdint.h>␊ |
| 55 | ␊ |
| 56 | /*␊ |
| 57 | * Format of a relocation entry of a Mach-O file. Modified from the 4.3BSD␊ |
| 58 | * format. The modifications from the original format were changing the value␊ |
| 59 | * of the r_symbolnum field for "local" (r_extern == 0) relocation entries.␊ |
| 60 | * This modification is required to support symbols in an arbitrary number of␊ |
| 61 | * sections not just the three sections (text, data and bss) in a 4.3BSD file.␊ |
| 62 | * Also the last 4 bits have had the r_type tag added to them.␊ |
| 63 | */␊ |
| 64 | struct relocation_info {␊ |
| 65 | int32_t␉r_address;␉/* offset in the section to what is being␊ |
| 66 | ␉␉␉␉ relocated */␊ |
| 67 | uint32_t r_symbolnum:24,␉/* symbol index if r_extern == 1 or section␊ |
| 68 | ␉␉␉␉ ordinal if r_extern == 0 */␊ |
| 69 | ␉␉r_pcrel:1, ␉/* was relocated pc relative already */␊ |
| 70 | ␉␉r_length:2,␉/* 0=byte, 1=word, 2=long, 3=quad */␊ |
| 71 | ␉␉r_extern:1,␉/* does not include value of sym referenced */␊ |
| 72 | ␉␉r_type:4;␉/* if not 0, machine specific relocation type */␊ |
| 73 | };␊ |
| 74 | #define␉R_ABS␉0␉␉/* absolute relocation type for Mach-O files */␊ |
| 75 | ␊ |
| 76 | /*␊ |
| 77 | * The r_address is not really the address as it's name indicates but an offset.␊ |
| 78 | * In 4.3BSD a.out objects this offset is from the start of the "segment" for␊ |
| 79 | * which relocation entry is for (text or data). For Mach-O object files it is␊ |
| 80 | * also an offset but from the start of the "section" for which the relocation␊ |
| 81 | * entry is for. See comments in <mach-o/loader.h> about the r_address feild␊ |
| 82 | * in images for used with the dynamic linker.␊ |
| 83 | * ␊ |
| 84 | * In 4.3BSD a.out objects if r_extern is zero then r_symbolnum is an ordinal␊ |
| 85 | * for the segment the symbol being relocated is in. These ordinals are the␊ |
| 86 | * symbol types N_TEXT, N_DATA, N_BSS or N_ABS. In Mach-O object files these␊ |
| 87 | * ordinals refer to the sections in the object file in the order their section␊ |
| 88 | * structures appear in the headers of the object file they are in. The first␊ |
| 89 | * section has the ordinal 1, the second 2, and so on. This means that the␊ |
| 90 | * same ordinal in two different object files could refer to two different␊ |
| 91 | * sections. And further could have still different ordinals when combined␊ |
| 92 | * by the link-editor. The value R_ABS is used for relocation entries for␊ |
| 93 | * absolute symbols which need no further relocation.␊ |
| 94 | */␊ |
| 95 | ␊ |
| 96 | /*␊ |
| 97 | * For RISC machines some of the references are split across two instructions␊ |
| 98 | * and the instruction does not contain the complete value of the reference.␊ |
| 99 | * In these cases a second, or paired relocation entry, follows each of these␊ |
| 100 | * relocation entries, using a PAIR r_type, which contains the other part of the␊ |
| 101 | * reference not contained in the instruction. This other part is stored in the␊ |
| 102 | * pair's r_address field. The exact number of bits of the other part of the␊ |
| 103 | * reference store in the r_address field is dependent on the particular␊ |
| 104 | * relocation type for the particular architecture.␊ |
| 105 | */␊ |
| 106 | ␊ |
| 107 | /*␊ |
| 108 | * To make scattered loading by the link editor work correctly "local"␊ |
| 109 | * relocation entries can't be used when the item to be relocated is the value␊ |
| 110 | * of a symbol plus an offset (where the resulting expresion is outside the␊ |
| 111 | * block the link editor is moving, a blocks are divided at symbol addresses).␊ |
| 112 | * In this case. where the item is a symbol value plus offset, the link editor␊ |
| 113 | * needs to know more than just the section the symbol was defined. What is␊ |
| 114 | * needed is the actual value of the symbol without the offset so it can do the␊ |
| 115 | * relocation correctly based on where the value of the symbol got relocated to␊ |
| 116 | * not the value of the expression (with the offset added to the symbol value).␊ |
| 117 | * So for the NeXT 2.0 release no "local" relocation entries are ever used when␊ |
| 118 | * there is a non-zero offset added to a symbol. The "external" and "local"␊ |
| 119 | * relocation entries remain unchanged.␊ |
| 120 | *␊ |
| 121 | * The implemention is quite messy given the compatibility with the existing␊ |
| 122 | * relocation entry format. The ASSUMPTION is that a section will never be␊ |
| 123 | * bigger than 2**24 - 1 (0x00ffffff or 16,777,215) bytes. This assumption␊ |
| 124 | * allows the r_address (which is really an offset) to fit in 24 bits and high␊ |
| 125 | * bit of the r_address field in the relocation_info structure to indicate␊ |
| 126 | * it is really a scattered_relocation_info structure. Since these are only␊ |
| 127 | * used in places where "local" relocation entries are used and not where␊ |
| 128 | * "external" relocation entries are used the r_extern field has been removed.␊ |
| 129 | *␊ |
| 130 | * For scattered loading to work on a RISC machine where some of the references␊ |
| 131 | * are split across two instructions the link editor needs to be assured that␊ |
| 132 | * each reference has a unique 32 bit reference (that more than one reference is␊ |
| 133 | * NOT sharing the same high 16 bits for example) so it move each referenced␊ |
| 134 | * item independent of each other. Some compilers guarantees this but the␊ |
| 135 | * compilers don't so scattered loading can be done on those that do guarantee␊ |
| 136 | * this.␊ |
| 137 | */␊ |
| 138 | #if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)␊ |
| 139 | /*␊ |
| 140 | * The reason for the ifdef's of __BIG_ENDIAN__ and __LITTLE_ENDIAN__ are that␊ |
| 141 | * when stattered relocation entries were added the mistake of using a mask␊ |
| 142 | * against a structure that is made up of bit fields was used. To make this␊ |
| 143 | * design work this structure must be laid out in memory the same way so the␊ |
| 144 | * mask can be applied can check the same bit each time (r_scattered).␊ |
| 145 | */␊ |
| 146 | #endif /* defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__) */␊ |
| 147 | #define R_SCATTERED 0x80000000␉/* mask to be applied to the r_address field ␊ |
| 148 | ␉␉␉␉ of a relocation_info structure to tell that␊ |
| 149 | ␉␉␉␉ is is really a scattered_relocation_info␊ |
| 150 | ␉␉␉␉ stucture */␊ |
| 151 | struct scattered_relocation_info {␊ |
| 152 | #ifdef __BIG_ENDIAN__␊ |
| 153 | uint32_t␉r_scattered:1,␉/* 1=scattered, 0=non-scattered (see above) */␊ |
| 154 | ␉␉r_pcrel:1, ␉/* was relocated pc relative already */␊ |
| 155 | ␉␉r_length:2,␉/* 0=byte, 1=word, 2=long, 3=quad */␊ |
| 156 | ␉␉r_type:4,␉/* if not 0, machine specific relocation type */␊ |
| 157 | ␉␉r_address:24;␉/* offset in the section to what is being␊ |
| 158 | ␉␉␉␉ relocated */␊ |
| 159 | int32_t␉r_value;␉/* the value the item to be relocated is␊ |
| 160 | ␉␉␉␉ refering to (without any offset added) */␊ |
| 161 | #endif /* __BIG_ENDIAN__ */␊ |
| 162 | #ifdef __LITTLE_ENDIAN__␊ |
| 163 | uint32_t␊ |
| 164 | ␉␉r_address:24,␉/* offset in the section to what is being␊ |
| 165 | ␉␉␉␉ relocated */␊ |
| 166 | ␉␉r_type:4,␉/* if not 0, machine specific relocation type */␊ |
| 167 | ␉␉r_length:2,␉/* 0=byte, 1=word, 2=long, 3=quad */␊ |
| 168 | ␉␉r_pcrel:1, ␉/* was relocated pc relative already */␊ |
| 169 | ␉␉r_scattered:1;␉/* 1=scattered, 0=non-scattered (see above) */␊ |
| 170 | int32_t␉r_value;␉/* the value the item to be relocated is␊ |
| 171 | ␉␉␉␉ refering to (without any offset added) */␊ |
| 172 | #endif /* __LITTLE_ENDIAN__ */␊ |
| 173 | };␊ |
| 174 | ␊ |
| 175 | /*␊ |
| 176 | * Relocation types used in a generic implementation. Relocation entries for␊ |
| 177 | * normal things use the generic relocation as discribed above and their r_type␊ |
| 178 | * is GENERIC_RELOC_VANILLA (a value of zero).␊ |
| 179 | *␊ |
| 180 | * Another type of generic relocation, GENERIC_RELOC_SECTDIFF, is to support␊ |
| 181 | * the difference of two symbols defined in different sections. That is the␊ |
| 182 | * expression "symbol1 - symbol2 + constant" is a relocatable expression when␊ |
| 183 | * both symbols are defined in some section. For this type of relocation the␊ |
| 184 | * both relocations entries are scattered relocation entries. The value of␊ |
| 185 | * symbol1 is stored in the first relocation entry's r_value field and the␊ |
| 186 | * value of symbol2 is stored in the pair's r_value field.␊ |
| 187 | *␊ |
| 188 | * A special case for a prebound lazy pointer is needed to beable to set the␊ |
| 189 | * value of the lazy pointer back to its non-prebound state. This is done␊ |
| 190 | * using the GENERIC_RELOC_PB_LA_PTR r_type. This is a scattered relocation␊ |
| 191 | * entry where the r_value feild is the value of the lazy pointer not prebound.␊ |
| 192 | */␊ |
| 193 | enum reloc_type_generic␊ |
| 194 | {␊ |
| 195 | GENERIC_RELOC_VANILLA,␉/* generic relocation as discribed above */␊ |
| 196 | GENERIC_RELOC_PAIR,␉␉/* Only follows a GENERIC_RELOC_SECTDIFF */␊ |
| 197 | GENERIC_RELOC_SECTDIFF,␊ |
| 198 | GENERIC_RELOC_PB_LA_PTR,␉/* prebound lazy pointer */␊ |
| 199 | GENERIC_RELOC_LOCAL_SECTDIFF,␊ |
| 200 | GENERIC_RELOC_TLV␉␉/* thread local variables */␊ |
| 201 | };␊ |
| 202 | ␊ |
| 203 | #endif /* _MACHO_RELOC_H_ */␊ |
| 204 | |
