Back to index

cell-binutils  2.17cvs20070401
sun4.h
Go to the documentation of this file.
00001 /* SPARC-specific values for a.out files 
00002 
00003    Copyright 2001 Free Software Foundation, Inc.
00004 
00005    This program is free software; you can redistribute it and/or modify
00006    it under the terms of the GNU General Public License as published by
00007    the Free Software Foundation; either version 2 of the License, or
00008    (at your option) any later version.
00009    
00010    This program is distributed in the hope that it will be useful,
00011    but WITHOUT ANY WARRANTY; without even the implied warranty of
00012    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
00013    GNU General Public License for more details.
00014    
00015    You should have received a copy of the GNU General Public License
00016    along with this program; if not, write to the Free Software
00017    Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA 02110-1301, USA.  */
00018 
00019 /* Some systems, e.g., AIX, may have defined this in header files already
00020    included.  */
00021 #undef  TARGET_PAGE_SIZE
00022 #define TARGET_PAGE_SIZE    0x2000        /* 8K.  aka NBPG in <sys/param.h> */
00023 /* Note that some SPARCs have 4K pages, some 8K, some others.  */
00024 
00025 #define SEG_SIZE_SPARC      TARGET_PAGE_SIZE
00026 #define       SEG_SIZE_SUN3 0x20000              /* Resolution of r/w protection hw */
00027 
00028 #define TEXT_START_ADDR     TARGET_PAGE_SIZE     /* Location 0 is not accessible */
00029 #define N_HEADER_IN_TEXT(x) 1
00030 
00031 /* Non-default definitions of the accessor macros... */
00032 
00033 /* Segment size varies on Sun-3 versus Sun-4.  */
00034 
00035 #define N_SEGSIZE(x) (N_MACHTYPE(x) == M_SPARC?  SEG_SIZE_SPARC:      \
00036                       N_MACHTYPE(x) == M_68020?  SEG_SIZE_SUN3:       \
00037                      /* Guess? */                TARGET_PAGE_SIZE)
00038 
00039 /* Virtual Address of text segment from the a.out file.  For OMAGIC,
00040    (almost always "unlinked .o's" these days), should be zero.
00041    Sun added a kludge so that shared libraries linked ZMAGIC get
00042    an address of zero if a_entry (!!!) is lower than the otherwise
00043    expected text address.  These kludges have gotta go!
00044    For linked files, should reflect reality if we know it.  */
00045 
00046 /* This differs from the version in aout64.h (which we override by defining
00047    it here) only for NMAGIC (we return TEXT_START_ADDR+EXEC_BYTES_SIZE;
00048    they return 0).  */
00049 
00050 #define N_TXTADDR(x) \
00051     (N_MAGIC(x)==OMAGIC? 0 \
00052      : (N_MAGIC(x) == ZMAGIC && (x).a_entry < TEXT_START_ADDR)? 0 \
00053      : TEXT_START_ADDR+EXEC_BYTES_SIZE)
00054 
00055 /* When a file is linked against a shared library on SunOS 4, the
00056    dynamic bit in the exec header is set, and the first symbol in the
00057    symbol table is __DYNAMIC.  Its value is the address of the
00058    following structure.  */
00059 
00060 struct external_sun4_dynamic
00061 {
00062   /* The version number of the structure.  SunOS 4.1.x creates files
00063      with version number 3, which is what this structure is based on.
00064      According to gdb, version 2 is similar.  I believe that version 2
00065      used a different type of procedure linkage table, and there may
00066      have been other differences.  */
00067   bfd_byte ld_version[4];
00068   /* The virtual address of a 28 byte structure used in debugging.
00069      The contents are filled in at run time by ld.so.  */
00070   bfd_byte ldd[4];
00071   /* The virtual address of another structure with information about
00072      how to relocate the executable at run time.  */
00073   bfd_byte ld[4];
00074 };
00075 
00076 /* The size of the debugging structure pointed to by the debugger
00077    field of __DYNAMIC.  */
00078 #define EXTERNAL_SUN4_DYNAMIC_DEBUGGER_SIZE (24)
00079 
00080 /* The structure pointed to by the linker field of __DYNAMIC.  As far
00081    as I can tell, most of the addresses in this structure are offsets
00082    within the file, but some are actually virtual addresses.  */
00083 
00084 struct internal_sun4_dynamic_link
00085 {
00086   /* Linked list of loaded objects.  This is filled in at runtime by
00087      ld.so and probably by dlopen.  */
00088   unsigned long ld_loaded;
00089 
00090   /* The address of the list of names of shared objects which must be
00091      included at runtime.  Each entry in the list is 16 bytes: the 4
00092      byte address of the string naming the object (e.g., for -lc this
00093      is "c"); 4 bytes of flags--the high bit is whether to search for
00094      the object using the library path; the 2 byte major version
00095      number; the 2 byte minor version number; the 4 byte address of
00096      the next entry in the list (zero if this is the last entry).  The
00097      version numbers seem to only be non-zero when doing library
00098      searching.  */
00099   unsigned long ld_need;
00100 
00101   /* The address of the path to search for the shared objects which
00102      must be included.  This points to a string in PATH format which
00103      is generated from the -L arguments to the linker.  According to
00104      the man page, ld.so implicitly adds ${LD_LIBRARY_PATH} to the
00105      beginning of this string and /lib:/usr/lib:/usr/local/lib to the
00106      end.  The string is terminated by a null byte.  This field is
00107      zero if there is no additional path.  */
00108   unsigned long ld_rules;
00109 
00110   /* The address of the global offset table.  This appears to be a
00111      virtual address, not a file offset.  The first entry in the
00112      global offset table seems to be the virtual address of the
00113      sun4_dynamic structure (the same value as the __DYNAMIC symbol).
00114      The global offset table is used for PIC code to hold the
00115      addresses of variables.  A dynamically linked file which does not
00116      itself contain PIC code has a four byte global offset table.  */
00117   unsigned long ld_got;
00118 
00119   /* The address of the procedure linkage table.  This appears to be a
00120      virtual address, not a file offset.
00121 
00122      On a SPARC, the table is composed of 12 byte entries, each of
00123      which consists of three instructions.  The first entry is
00124          sethi %hi(0),%g1
00125         jmp %g1
00126         nop
00127      These instructions are changed by ld.so into a jump directly into
00128      ld.so itself.  Each subsequent entry is
00129          save %sp, -96, %sp
00130         call <address of first entry in procedure linkage table>
00131         <reloc_number | 0x01000000>
00132      The reloc_number is the number of the reloc to use to resolve
00133      this entry.  The reloc will be a JMP_SLOT reloc against some
00134      symbol that is not defined in this object file but should be
00135      defined in a shared object (if it is not, ld.so will report a
00136      runtime error and exit).  The constant 0x010000000 turns the
00137      reloc number into a sethi of %g0, which does nothing since %g0 is
00138      hardwired to zero.
00139 
00140      When one of these entries is executed, it winds up calling into
00141      ld.so.  ld.so looks at the reloc number, available via the return
00142      address, to determine which entry this is.  It then looks at the
00143      reloc and patches up the entry in the table into a sethi and jmp
00144      to the real address followed by a nop.  This means that the reloc
00145      lookup only has to happen once, and it also means that the
00146      relocation only needs to be done if the function is actually
00147      called.  The relocation is expensive because ld.so must look up
00148      the symbol by name.
00149 
00150      The size of the procedure linkage table is given by the ld_plt_sz
00151      field.  */
00152   unsigned long ld_plt;
00153 
00154   /* The address of the relocs.  These are in the same format as
00155      ordinary relocs.  Symbol index numbers refer to the symbols
00156      pointed to by ld_stab.  I think the only way to determine the
00157      number of relocs is to assume that all the bytes from ld_rel to
00158      ld_hash contain reloc entries.  */
00159   unsigned long ld_rel;
00160 
00161   /* The address of a hash table of symbols.  The hash table has
00162      roughly the same number of entries as there are dynamic symbols;
00163      I think the only way to get the exact size is to assume that
00164      every byte from ld_hash to ld_stab is devoted to the hash table.
00165 
00166      Each entry in the hash table is eight bytes.  The first four
00167      bytes are a symbol index into the dynamic symbols.  The second
00168      four bytes are the index of the next hash table entry in the
00169      bucket.  The ld_buckets field gives the number of buckets, say B.
00170      The first B entries in the hash table each start a bucket which
00171      is chained through the second four bytes of each entry.  A value
00172      of zero ends the chain.
00173 
00174      The hash function is simply
00175          h = 0;
00176          while (*string != '\0')
00177           h = (h << 1) + *string++;
00178         h &= 0x7fffffff;
00179 
00180      To look up a symbol, compute the hash value of the name.  Take
00181      the modulos of hash value and the number of buckets.  Start at
00182      that entry in the hash table.  See if the symbol (from the first
00183      four bytes of the hash table entry) has the name you are looking
00184      for.  If not, use the chain field (the second four bytes of the
00185      hash table entry) to move on to the next entry in this bucket.
00186      If the chain field is zero you have reached the end of the
00187      bucket, and the symbol is not in the hash table.  */ 
00188   unsigned long ld_hash;
00189 
00190   /* The address of the symbol table.  This is a list of
00191      external_nlist structures.  The string indices are relative to
00192      the ld_symbols field.  I think the only way to determine the
00193      number of symbols is to assume that all the bytes between ld_stab
00194      and ld_symbols are external_nlist structures.  */
00195   unsigned long ld_stab;
00196 
00197   /* I don't know what this is for.  It seems to always be zero.  */
00198   unsigned long ld_stab_hash;
00199 
00200   /* The number of buckets in the hash table.  */
00201   unsigned long ld_buckets;
00202 
00203   /* The address of the symbol string table.  The first string in this
00204      string table need not be the empty string.  */
00205   unsigned long ld_symbols;
00206 
00207   /* The size in bytes of the symbol string table.  */
00208   unsigned long ld_symb_size;
00209 
00210   /* The size in bytes of the text segment.  */
00211   unsigned long ld_text;
00212 
00213   /* The size in bytes of the procedure linkage table.  */
00214   unsigned long ld_plt_sz;
00215 };
00216 
00217 /* The external form of the structure.  */
00218 
00219 struct external_sun4_dynamic_link
00220 {
00221   bfd_byte ld_loaded[4];
00222   bfd_byte ld_need[4];
00223   bfd_byte ld_rules[4];
00224   bfd_byte ld_got[4];
00225   bfd_byte ld_plt[4];
00226   bfd_byte ld_rel[4];
00227   bfd_byte ld_hash[4];
00228   bfd_byte ld_stab[4];
00229   bfd_byte ld_stab_hash[4];
00230   bfd_byte ld_buckets[4];
00231   bfd_byte ld_symbols[4];
00232   bfd_byte ld_symb_size[4];
00233   bfd_byte ld_text[4];
00234   bfd_byte ld_plt_sz[4];
00235 };