xref: /openbsd-src/gnu/usr.bin/binutils/include/aout/sun4.h (revision b2ea75c1b17e1a9a339660e7ed45cd24946b230e)
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 };
220