* config/i386/tm-i386.h (PARM_BOUNDARY, CALL_DUMMY,

[deliverable/binutils-gdb.git] / gdb / somread.c

diff --git a/gdb/somread.c b/gdb/somread.c
index e4fec18ae624119c25a3c07c875eacdd2a26824a..38e35b2e7bbd5d2043fc4f67d4052a2ab18e0ab7 100644 (file)
--- a/gdb/somread.c
+++ b/gdb/somread.c
@@ -117,20 +117,13 @@ som_symtab_read (bfd *abfd, struct objfile *objfile,
      can do the right thing for ST_ENTRY vs ST_CODE symbols).
 
      There's nothing in the header which easily allows us to do
-     this.  The only reliable way I know of is to check for the
-     existence of a $SHLIB_INFO$ section with a non-zero size.  */
-  /* The code below is not a reliable way to check whether an
-   * executable is dynamic, so I commented it out - RT
-   * shlib_info = bfd_get_section_by_name (objfile->obfd, "$SHLIB_INFO$");
-   * if (shlib_info)
-   *   dynamic = (bfd_section_size (objfile->obfd, shlib_info) != 0);
-   * else
-   *   dynamic = 0;
-   */
-  /* I replaced the code with a simple check for text offset not being
-   * zero. Still not 100% reliable, but a more reliable way of asking
-   * "is this a dynamic executable?" than the above. RT
-   */
+     this.
+
+     This code used to rely upon the existence of a $SHLIB_INFO$
+     section to make this determination.  HP claims that it is
+     more accurate to check for a nonzero text offset, but they
+     have not provided any information about why that test is
+     more accurate.  */
   dynamic = (text_offset != 0);
 
   endbufp = buf + number_of_symbols;
@@ -240,13 +233,11 @@ som_symtab_read (bfd *abfd, struct objfile *objfile,
 
            case ST_ENTRY:
              symname = bufp->name.n_strx + stringtab;
-             /* For a dynamic executable, ST_ENTRY symbols are
-                the stubs, while the ST_CODE symbol is the real
-                function.  */
-             if (dynamic)
-               ms_type = mst_solib_trampoline;
-             else
-               ms_type = mst_file_text;
+             /* SS_LOCAL symbols in a shared library do not have
+                export stubs, so we do not have to worry about
+                using mst_file_text vs mst_solib_trampoline here like
+                we do for SS_UNIVERSAL and SS_EXTERNAL symbols above.  */
+             ms_type = mst_file_text;
              bufp->symbol_value += text_offset;
              bufp->symbol_value = SMASH_TEXT_ADDRESS (bufp->symbol_value);
              break;