Go to most recent revision | Details | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
5191 | serge | 1 | /* SPARC-specific values for a.out files |
2 | |||
3 | Copyright 2001, 2009, 2010 Free Software Foundation, Inc. |
||
4 | |||
5 | This program is free software; you can redistribute it and/or modify |
||
6 | it under the terms of the GNU General Public License as published by |
||
7 | the Free Software Foundation; either version 3 of the License, or |
||
8 | (at your option) any later version. |
||
9 | |||
10 | This program is distributed in the hope that it will be useful, |
||
11 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
||
12 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
||
13 | GNU General Public License for more details. |
||
14 | |||
15 | You should have received a copy of the GNU General Public License |
||
16 | along with this program; if not, write to the Free Software |
||
17 | Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, |
||
18 | MA 02110-1301, USA. */ |
||
19 | |||
20 | /* Some systems, e.g., AIX, may have defined this in header files already |
||
21 | included. */ |
||
22 | #undef TARGET_PAGE_SIZE |
||
23 | #define TARGET_PAGE_SIZE 0x2000 /* 8K. aka NBPG in |
||
24 | /* Note that some SPARCs have 4K pages, some 8K, some others. */ |
||
25 | |||
26 | #define SEG_SIZE_SPARC TARGET_PAGE_SIZE |
||
27 | #define SEG_SIZE_SUN3 0x20000 /* Resolution of r/w protection hw */ |
||
28 | |||
29 | #define TEXT_START_ADDR TARGET_PAGE_SIZE /* Location 0 is not accessible */ |
||
30 | #define N_HEADER_IN_TEXT(x) 1 |
||
31 | |||
32 | /* Non-default definitions of the accessor macros... */ |
||
33 | |||
34 | /* Segment size varies on Sun-3 versus Sun-4. */ |
||
35 | |||
36 | #define N_SEGSIZE(x) (N_MACHTYPE(x) == M_SPARC? SEG_SIZE_SPARC: \ |
||
37 | N_MACHTYPE(x) == M_68020? SEG_SIZE_SUN3: \ |
||
38 | /* Guess? */ TARGET_PAGE_SIZE) |
||
39 | |||
40 | /* Virtual Address of text segment from the a.out file. For OMAGIC, |
||
41 | (almost always "unlinked .o's" these days), should be zero. |
||
42 | Sun added a kludge so that shared libraries linked ZMAGIC get |
||
43 | an address of zero if a_entry (!!!) is lower than the otherwise |
||
44 | expected text address. These kludges have gotta go! |
||
45 | For linked files, should reflect reality if we know it. */ |
||
46 | |||
47 | #define N_SHARED_LIB(x) ((x).a_entry < TEXT_START_ADDR \ |
||
48 | && (x).a_text >= EXEC_BYTES_SIZE) |
||
49 | |||
50 | /* This differs from the version in aout64.h (which we override by defining |
||
51 | it here) only for NMAGIC (we return TEXT_START_ADDR+EXEC_BYTES_SIZE; |
||
52 | they return 0). */ |
||
53 | |||
54 | #define N_TXTADDR(x) \ |
||
55 | (N_MAGIC(x)==OMAGIC? 0 \ |
||
56 | : (N_MAGIC(x) == ZMAGIC && (x).a_entry < TEXT_START_ADDR)? 0 \ |
||
57 | : TEXT_START_ADDR+EXEC_BYTES_SIZE) |
||
58 | |||
59 | /* When a file is linked against a shared library on SunOS 4, the |
||
60 | dynamic bit in the exec header is set, and the first symbol in the |
||
61 | symbol table is __DYNAMIC. Its value is the address of the |
||
62 | following structure. */ |
||
63 | |||
64 | struct external_sun4_dynamic |
||
65 | { |
||
66 | /* The version number of the structure. SunOS 4.1.x creates files |
||
67 | with version number 3, which is what this structure is based on. |
||
68 | According to gdb, version 2 is similar. I believe that version 2 |
||
69 | used a different type of procedure linkage table, and there may |
||
70 | have been other differences. */ |
||
71 | bfd_byte ld_version[4]; |
||
72 | /* The virtual address of a 28 byte structure used in debugging. |
||
73 | The contents are filled in at run time by ld.so. */ |
||
74 | bfd_byte ldd[4]; |
||
75 | /* The virtual address of another structure with information about |
||
76 | how to relocate the executable at run time. */ |
||
77 | bfd_byte ld[4]; |
||
78 | }; |
||
79 | |||
80 | /* The size of the debugging structure pointed to by the debugger |
||
81 | field of __DYNAMIC. */ |
||
82 | #define EXTERNAL_SUN4_DYNAMIC_DEBUGGER_SIZE (24) |
||
83 | |||
84 | /* The structure pointed to by the linker field of __DYNAMIC. As far |
||
85 | as I can tell, most of the addresses in this structure are offsets |
||
86 | within the file, but some are actually virtual addresses. */ |
||
87 | |||
88 | struct internal_sun4_dynamic_link |
||
89 | { |
||
90 | /* Linked list of loaded objects. This is filled in at runtime by |
||
91 | ld.so and probably by dlopen. */ |
||
92 | unsigned long ld_loaded; |
||
93 | |||
94 | /* The address of the list of names of shared objects which must be |
||
95 | included at runtime. Each entry in the list is 16 bytes: the 4 |
||
96 | byte address of the string naming the object (e.g., for -lc this |
||
97 | is "c"); 4 bytes of flags--the high bit is whether to search for |
||
98 | the object using the library path; the 2 byte major version |
||
99 | number; the 2 byte minor version number; the 4 byte address of |
||
100 | the next entry in the list (zero if this is the last entry). The |
||
101 | version numbers seem to only be non-zero when doing library |
||
102 | searching. */ |
||
103 | unsigned long ld_need; |
||
104 | |||
105 | /* The address of the path to search for the shared objects which |
||
106 | must be included. This points to a string in PATH format which |
||
107 | is generated from the -L arguments to the linker. According to |
||
108 | the man page, ld.so implicitly adds ${LD_LIBRARY_PATH} to the |
||
109 | beginning of this string and /lib:/usr/lib:/usr/local/lib to the |
||
110 | end. The string is terminated by a null byte. This field is |
||
111 | zero if there is no additional path. */ |
||
112 | unsigned long ld_rules; |
||
113 | |||
114 | /* The address of the global offset table. This appears to be a |
||
115 | virtual address, not a file offset. The first entry in the |
||
116 | global offset table seems to be the virtual address of the |
||
117 | sun4_dynamic structure (the same value as the __DYNAMIC symbol). |
||
118 | The global offset table is used for PIC code to hold the |
||
119 | addresses of variables. A dynamically linked file which does not |
||
120 | itself contain PIC code has a four byte global offset table. */ |
||
121 | unsigned long ld_got; |
||
122 | |||
123 | /* The address of the procedure linkage table. This appears to be a |
||
124 | virtual address, not a file offset. |
||
125 | |||
126 | On a SPARC, the table is composed of 12 byte entries, each of |
||
127 | which consists of three instructions. The first entry is |
||
128 | sethi %hi(0),%g1 |
||
129 | jmp %g1 |
||
130 | nop |
||
131 | These instructions are changed by ld.so into a jump directly into |
||
132 | ld.so itself. Each subsequent entry is |
||
133 | save %sp, -96, %sp |
||
134 | call |
||
135 | |||
136 | The reloc_number is the number of the reloc to use to resolve |
||
137 | this entry. The reloc will be a JMP_SLOT reloc against some |
||
138 | symbol that is not defined in this object file but should be |
||
139 | defined in a shared object (if it is not, ld.so will report a |
||
140 | runtime error and exit). The constant 0x010000000 turns the |
||
141 | reloc number into a sethi of %g0, which does nothing since %g0 is |
||
142 | hardwired to zero. |
||
143 | |||
144 | When one of these entries is executed, it winds up calling into |
||
145 | ld.so. ld.so looks at the reloc number, available via the return |
||
146 | address, to determine which entry this is. It then looks at the |
||
147 | reloc and patches up the entry in the table into a sethi and jmp |
||
148 | to the real address followed by a nop. This means that the reloc |
||
149 | lookup only has to happen once, and it also means that the |
||
150 | relocation only needs to be done if the function is actually |
||
151 | called. The relocation is expensive because ld.so must look up |
||
152 | the symbol by name. |
||
153 | |||
154 | The size of the procedure linkage table is given by the ld_plt_sz |
||
155 | field. */ |
||
156 | unsigned long ld_plt; |
||
157 | |||
158 | /* The address of the relocs. These are in the same format as |
||
159 | ordinary relocs. Symbol index numbers refer to the symbols |
||
160 | pointed to by ld_stab. I think the only way to determine the |
||
161 | number of relocs is to assume that all the bytes from ld_rel to |
||
162 | ld_hash contain reloc entries. */ |
||
163 | unsigned long ld_rel; |
||
164 | |||
165 | /* The address of a hash table of symbols. The hash table has |
||
166 | roughly the same number of entries as there are dynamic symbols; |
||
167 | I think the only way to get the exact size is to assume that |
||
168 | every byte from ld_hash to ld_stab is devoted to the hash table. |
||
169 | |||
170 | Each entry in the hash table is eight bytes. The first four |
||
171 | bytes are a symbol index into the dynamic symbols. The second |
||
172 | four bytes are the index of the next hash table entry in the |
||
173 | bucket. The ld_buckets field gives the number of buckets, say B. |
||
174 | The first B entries in the hash table each start a bucket which |
||
175 | is chained through the second four bytes of each entry. A value |
||
176 | of zero ends the chain. |
||
177 | |||
178 | The hash function is simply |
||
179 | h = 0; |
||
180 | while (*string != '\0') |
||
181 | h = (h << 1) + *string++; |
||
182 | h &= 0x7fffffff; |
||
183 | |||
184 | To look up a symbol, compute the hash value of the name. Take |
||
185 | the modulos of hash value and the number of buckets. Start at |
||
186 | that entry in the hash table. See if the symbol (from the first |
||
187 | four bytes of the hash table entry) has the name you are looking |
||
188 | for. If not, use the chain field (the second four bytes of the |
||
189 | hash table entry) to move on to the next entry in this bucket. |
||
190 | If the chain field is zero you have reached the end of the |
||
191 | bucket, and the symbol is not in the hash table. */ |
||
192 | unsigned long ld_hash; |
||
193 | |||
194 | /* The address of the symbol table. This is a list of |
||
195 | external_nlist structures. The string indices are relative to |
||
196 | the ld_symbols field. I think the only way to determine the |
||
197 | number of symbols is to assume that all the bytes between ld_stab |
||
198 | and ld_symbols are external_nlist structures. */ |
||
199 | unsigned long ld_stab; |
||
200 | |||
201 | /* I don't know what this is for. It seems to always be zero. */ |
||
202 | unsigned long ld_stab_hash; |
||
203 | |||
204 | /* The number of buckets in the hash table. */ |
||
205 | unsigned long ld_buckets; |
||
206 | |||
207 | /* The address of the symbol string table. The first string in this |
||
208 | string table need not be the empty string. */ |
||
209 | unsigned long ld_symbols; |
||
210 | |||
211 | /* The size in bytes of the symbol string table. */ |
||
212 | unsigned long ld_symb_size; |
||
213 | |||
214 | /* The size in bytes of the text segment. */ |
||
215 | unsigned long ld_text; |
||
216 | |||
217 | /* The size in bytes of the procedure linkage table. */ |
||
218 | unsigned long ld_plt_sz; |
||
219 | }; |
||
220 | |||
221 | /* The external form of the structure. */ |
||
222 | |||
223 | struct external_sun4_dynamic_link |
||
224 | { |
||
225 | bfd_byte ld_loaded[4]; |
||
226 | bfd_byte ld_need[4]; |
||
227 | bfd_byte ld_rules[4]; |
||
228 | bfd_byte ld_got[4]; |
||
229 | bfd_byte ld_plt[4]; |
||
230 | bfd_byte ld_rel[4]; |
||
231 | bfd_byte ld_hash[4]; |
||
232 | bfd_byte ld_stab[4]; |
||
233 | bfd_byte ld_stab_hash[4]; |
||
234 | bfd_byte ld_buckets[4]; |
||
235 | bfd_byte ld_symbols[4]; |
||
236 | bfd_byte ld_symb_size[4]; |
||
237 | bfd_byte ld_text[4]; |
||
238 | bfd_byte ld_plt_sz[4]; |
||
239 | };><>>> |