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