Commit | Line | Data |
---|---|---|
252b5132 RH |
1 | /* SPARC-specific values for a.out files */ |
2 | ||
3 | /* Some systems, e.g., AIX, may have defined this in header files already | |
4 | included. */ | |
5 | #undef TARGET_PAGE_SIZE | |
6 | #define TARGET_PAGE_SIZE 0x2000 /* 8K. aka NBPG in <sys/param.h> */ | |
7 | /* Note that some SPARCs have 4K pages, some 8K, some others. */ | |
8 | ||
9 | #define SEG_SIZE_SPARC TARGET_PAGE_SIZE | |
10 | #define SEG_SIZE_SUN3 0x20000 /* Resolution of r/w protection hw */ | |
11 | ||
12 | #define TEXT_START_ADDR TARGET_PAGE_SIZE /* Location 0 is not accessible */ | |
13 | #define N_HEADER_IN_TEXT(x) 1 | |
14 | ||
15 | /* Non-default definitions of the accessor macros... */ | |
16 | ||
17 | /* Segment size varies on Sun-3 versus Sun-4. */ | |
18 | ||
19 | #define N_SEGSIZE(x) (N_MACHTYPE(x) == M_SPARC? SEG_SIZE_SPARC: \ | |
20 | N_MACHTYPE(x) == M_68020? SEG_SIZE_SUN3: \ | |
21 | /* Guess? */ TARGET_PAGE_SIZE) | |
22 | ||
23 | /* Virtual Address of text segment from the a.out file. For OMAGIC, | |
24 | (almost always "unlinked .o's" these days), should be zero. | |
25 | Sun added a kludge so that shared libraries linked ZMAGIC get | |
26 | an address of zero if a_entry (!!!) is lower than the otherwise | |
27 | expected text address. These kludges have gotta go! | |
28 | For linked files, should reflect reality if we know it. */ | |
29 | ||
30 | /* This differs from the version in aout64.h (which we override by defining | |
31 | it here) only for NMAGIC (we return TEXT_START_ADDR+EXEC_BYTES_SIZE; | |
32 | they return 0). */ | |
33 | ||
34 | #define N_TXTADDR(x) \ | |
35 | (N_MAGIC(x)==OMAGIC? 0 \ | |
36 | : (N_MAGIC(x) == ZMAGIC && (x).a_entry < TEXT_START_ADDR)? 0 \ | |
37 | : TEXT_START_ADDR+EXEC_BYTES_SIZE) | |
38 | ||
39 | /* When a file is linked against a shared library on SunOS 4, the | |
40 | dynamic bit in the exec header is set, and the first symbol in the | |
41 | symbol table is __DYNAMIC. Its value is the address of the | |
42 | following structure. */ | |
43 | ||
44 | struct external_sun4_dynamic | |
45 | { | |
46 | /* The version number of the structure. SunOS 4.1.x creates files | |
47 | with version number 3, which is what this structure is based on. | |
48 | According to gdb, version 2 is similar. I believe that version 2 | |
49 | used a different type of procedure linkage table, and there may | |
50 | have been other differences. */ | |
51 | bfd_byte ld_version[4]; | |
52 | /* The virtual address of a 28 byte structure used in debugging. | |
53 | The contents are filled in at run time by ld.so. */ | |
54 | bfd_byte ldd[4]; | |
55 | /* The virtual address of another structure with information about | |
56 | how to relocate the executable at run time. */ | |
57 | bfd_byte ld[4]; | |
58 | }; | |
59 | ||
60 | /* The size of the debugging structure pointed to by the debugger | |
61 | field of __DYNAMIC. */ | |
62 | #define EXTERNAL_SUN4_DYNAMIC_DEBUGGER_SIZE (24) | |
63 | ||
64 | /* The structure pointed to by the linker field of __DYNAMIC. As far | |
65 | as I can tell, most of the addresses in this structure are offsets | |
66 | within the file, but some are actually virtual addresses. */ | |
67 | ||
68 | struct internal_sun4_dynamic_link | |
69 | { | |
70 | /* Linked list of loaded objects. This is filled in at runtime by | |
71 | ld.so and probably by dlopen. */ | |
72 | unsigned long ld_loaded; | |
73 | ||
74 | /* The address of the list of names of shared objects which must be | |
75 | included at runtime. Each entry in the list is 16 bytes: the 4 | |
76 | byte address of the string naming the object (e.g., for -lc this | |
77 | 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 | ||
203 | struct 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 | }; |