sun4.h revision 59024
160484Sobrien/* SPARC-specific values for a.out files */ 233965Sjdp 333965Sjdp/* Some systems, e.g., AIX, may have defined this in header files already 433965Sjdp included. */ 533965Sjdp#undef TARGET_PAGE_SIZE 633965Sjdp#define TARGET_PAGE_SIZE 0x2000 /* 8K. aka NBPG in <sys/param.h> */ 733965Sjdp/* Note that some SPARCs have 4K pages, some 8K, some others. */ 833965Sjdp 933965Sjdp#define SEG_SIZE_SPARC TARGET_PAGE_SIZE 1033965Sjdp#define SEG_SIZE_SUN3 0x20000 /* Resolution of r/w protection hw */ 1133965Sjdp 1233965Sjdp#define TEXT_START_ADDR TARGET_PAGE_SIZE /* Location 0 is not accessible */ 1333965Sjdp#define N_HEADER_IN_TEXT(x) 1 1433965Sjdp 1533965Sjdp/* Non-default definitions of the accessor macros... */ 1633965Sjdp 1733965Sjdp/* Segment size varies on Sun-3 versus Sun-4. */ 1833965Sjdp 1933965Sjdp#define N_SEGSIZE(x) (N_MACHTYPE(x) == M_SPARC? SEG_SIZE_SPARC: \ 2033965Sjdp N_MACHTYPE(x) == M_68020? SEG_SIZE_SUN3: \ 2133965Sjdp /* Guess? */ TARGET_PAGE_SIZE) 2233965Sjdp 2333965Sjdp/* Virtual Address of text segment from the a.out file. For OMAGIC, 2433965Sjdp (almost always "unlinked .o's" these days), should be zero. 2533965Sjdp Sun added a kludge so that shared libraries linked ZMAGIC get 2633965Sjdp an address of zero if a_entry (!!!) is lower than the otherwise 2733965Sjdp expected text address. These kludges have gotta go! 2833965Sjdp For linked files, should reflect reality if we know it. */ 2938889Sjdp 3038889Sjdp/* This differs from the version in aout64.h (which we override by defining 3133965Sjdp it here) only for NMAGIC (we return TEXT_START_ADDR+EXEC_BYTES_SIZE; 3260484Sobrien they return 0). */ 3333965Sjdp 3433965Sjdp#define N_TXTADDR(x) \ 3560484Sobrien (N_MAGIC(x)==OMAGIC? 0 \ 3660484Sobrien : (N_MAGIC(x) == ZMAGIC && (x).a_entry < TEXT_START_ADDR)? 0 \ 3733965Sjdp : TEXT_START_ADDR+EXEC_BYTES_SIZE) 3877298Sobrien 3933965Sjdp/* When a file is linked against a shared library on SunOS 4, the 4038889Sjdp dynamic bit in the exec header is set, and the first symbol in the 4177298Sobrien symbol table is __DYNAMIC. Its value is the address of the 4233965Sjdp following structure. */ 4360484Sobrien 4460484Sobrienstruct external_sun4_dynamic 4560484Sobrien{ 4660484Sobrien /* The version number of the structure. SunOS 4.1.x creates files 4733965Sjdp with version number 3, which is what this structure is based on. 4877298Sobrien According to gdb, version 2 is similar. I believe that version 2 4960484Sobrien used a different type of procedure linkage table, and there may 5033965Sjdp have been other differences. */ 5133965Sjdp bfd_byte ld_version[4]; 5260484Sobrien /* The virtual address of a 28 byte structure used in debugging. 5333965Sjdp The contents are filled in at run time by ld.so. */ 5433965Sjdp bfd_byte ldd[4]; 5533965Sjdp /* The virtual address of another structure with information about 5633965Sjdp how to relocate the executable at run time. */ 5733965Sjdp bfd_byte ld[4]; 5833965Sjdp}; 5933965Sjdp 6033965Sjdp/* The size of the debugging structure pointed to by the debugger 6133965Sjdp field of __DYNAMIC. */ 6233965Sjdp#define EXTERNAL_SUN4_DYNAMIC_DEBUGGER_SIZE (24) 6333965Sjdp 6433965Sjdp/* The structure pointed to by the linker field of __DYNAMIC. As far 6533965Sjdp as I can tell, most of the addresses in this structure are offsets 6633965Sjdp within the file, but some are actually virtual addresses. */ 6733965Sjdp 6833965Sjdpstruct internal_sun4_dynamic_link 6933965Sjdp{ 7033965Sjdp /* Linked list of loaded objects. This is filled in at runtime by 7133965Sjdp ld.so and probably by dlopen. */ 7233965Sjdp unsigned long ld_loaded; 7333965Sjdp 7433965Sjdp /* The address of the list of names of shared objects which must be 7533965Sjdp included at runtime. Each entry in the list is 16 bytes: the 4 7633965Sjdp byte address of the string naming the object (e.g., for -lc this 7733965Sjdp is "c"); 4 bytes of flags--the high bit is whether to search for 78 the object using the library path; the 2 byte major version 79 number; the 2 byte minor version number; the 4 byte address of 80 the next entry in the list (zero if this is the last entry). The 81 version numbers seem to only be non-zero when doing library 82 searching. */ 83 unsigned long ld_need; 84 85 /* The address of the path to search for the shared objects which 86 must be included. This points to a string in PATH format which 87 is generated from the -L arguments to the linker. According to 88 the man page, ld.so implicitly adds ${LD_LIBRARY_PATH} to the 89 beginning of this string and /lib:/usr/lib:/usr/local/lib to the 90 end. The string is terminated by a null byte. This field is 91 zero if there is no additional path. */ 92 unsigned long ld_rules; 93 94 /* The address of the global offset table. This appears to be a 95 virtual address, not a file offset. The first entry in the 96 global offset table seems to be the virtual address of the 97 sun4_dynamic structure (the same value as the __DYNAMIC symbol). 98 The global offset table is used for PIC code to hold the 99 addresses of variables. A dynamically linked file which does not 100 itself contain PIC code has a four byte global offset table. */ 101 unsigned long ld_got; 102 103 /* The address of the procedure linkage table. This appears to be a 104 virtual address, not a file offset. 105 106 On a SPARC, the table is composed of 12 byte entries, each of 107 which consists of three instructions. The first entry is 108 sethi %hi(0),%g1 109 jmp %g1 110 nop 111 These instructions are changed by ld.so into a jump directly into 112 ld.so itself. Each subsequent entry is 113 save %sp, -96, %sp 114 call <address of first entry in procedure linkage table> 115 <reloc_number | 0x01000000> 116 The reloc_number is the number of the reloc to use to resolve 117 this entry. The reloc will be a JMP_SLOT reloc against some 118 symbol that is not defined in this object file but should be 119 defined in a shared object (if it is not, ld.so will report a 120 runtime error and exit). The constant 0x010000000 turns the 121 reloc number into a sethi of %g0, which does nothing since %g0 is 122 hardwired to zero. 123 124 When one of these entries is executed, it winds up calling into 125 ld.so. ld.so looks at the reloc number, available via the return 126 address, to determine which entry this is. It then looks at the 127 reloc and patches up the entry in the table into a sethi and jmp 128 to the real address followed by a nop. This means that the reloc 129 lookup only has to happen once, and it also means that the 130 relocation only needs to be done if the function is actually 131 called. The relocation is expensive because ld.so must look up 132 the symbol by name. 133 134 The size of the procedure linkage table is given by the ld_plt_sz 135 field. */ 136 unsigned long ld_plt; 137 138 /* The address of the relocs. These are in the same format as 139 ordinary relocs. Symbol index numbers refer to the symbols 140 pointed to by ld_stab. I think the only way to determine the 141 number of relocs is to assume that all the bytes from ld_rel to 142 ld_hash contain reloc entries. */ 143 unsigned long ld_rel; 144 145 /* The address of a hash table of symbols. The hash table has 146 roughly the same number of entries as there are dynamic symbols; 147 I think the only way to get the exact size is to assume that 148 every byte from ld_hash to ld_stab is devoted to the hash table. 149 150 Each entry in the hash table is eight bytes. The first four 151 bytes are a symbol index into the dynamic symbols. The second 152 four bytes are the index of the next hash table entry in the 153 bucket. The ld_buckets field gives the number of buckets, say B. 154 The first B entries in the hash table each start a bucket which 155 is chained through the second four bytes of each entry. A value 156 of zero ends the chain. 157 158 The hash function is simply 159 h = 0; 160 while (*string != '\0') 161 h = (h << 1) + *string++; 162 h &= 0x7fffffff; 163 164 To look up a symbol, compute the hash value of the name. Take 165 the modulos of hash value and the number of buckets. Start at 166 that entry in the hash table. See if the symbol (from the first 167 four bytes of the hash table entry) has the name you are looking 168 for. If not, use the chain field (the second four bytes of the 169 hash table entry) to move on to the next entry in this bucket. 170 If the chain field is zero you have reached the end of the 171 bucket, and the symbol is not in the hash table. */ 172 unsigned long ld_hash; 173 174 /* The address of the symbol table. This is a list of 175 external_nlist structures. The string indices are relative to 176 the ld_symbols field. I think the only way to determine the 177 number of symbols is to assume that all the bytes between ld_stab 178 and ld_symbols are external_nlist structures. */ 179 unsigned long ld_stab; 180 181 /* I don't know what this is for. It seems to always be zero. */ 182 unsigned long ld_stab_hash; 183 184 /* The number of buckets in the hash table. */ 185 unsigned long ld_buckets; 186 187 /* The address of the symbol string table. The first string in this 188 string table need not be the empty string. */ 189 unsigned long ld_symbols; 190 191 /* The size in bytes of the symbol string table. */ 192 unsigned long ld_symb_size; 193 194 /* The size in bytes of the text segment. */ 195 unsigned long ld_text; 196 197 /* The size in bytes of the procedure linkage table. */ 198 unsigned long ld_plt_sz; 199}; 200 201/* The external form of the structure. */ 202 203struct external_sun4_dynamic_link 204{ 205 bfd_byte ld_loaded[4]; 206 bfd_byte ld_need[4]; 207 bfd_byte ld_rules[4]; 208 bfd_byte ld_got[4]; 209 bfd_byte ld_plt[4]; 210 bfd_byte ld_rel[4]; 211 bfd_byte ld_hash[4]; 212 bfd_byte ld_stab[4]; 213 bfd_byte ld_stab_hash[4]; 214 bfd_byte ld_buckets[4]; 215 bfd_byte ld_symbols[4]; 216 bfd_byte ld_symb_size[4]; 217 bfd_byte ld_text[4]; 218 bfd_byte ld_plt_sz[4]; 219}; 220