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