This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fix for SOM shared library problem



Static functions in shared libraries do not have export stubs and as a
result the only appear one time in the shared library's symbol table
with type ST_ENTRY.  The ST_ENTRY symbol's value is the function's
actual address.

Contrast this to dynamic functions in shared libraries which appear
twice in the symbol table.  One entry has type ST_ENTRY which is 
actually the export stub for the function.  The second symbol table
entry has type ST_CODE and represents the actual function.

The difference is important when determining the minimal symbol
table for each symbol.  Unfortunately somread.c was treating static
and dynamic symbols in the same way.  This resulted in static
functions having type mst_solib_trampoline instead of mst_file_text.
This caused a number of unpleasant problems.  The change to somsolib.c
fixes this problem.

The change to hppa-tdep.c merely prevents the debugger from dumping core
if it is unable to map from a PC value back to a minimal symbol (say if
you happen to be in the dynamic linker or if the program's symbol table
was stripped).


        * somread.c (som_symtab_read): Remove some commented out code and
        updated related comments.  Do not set the minimal symbol table to
        mst_solib_trampoline for ST_ENTRY symbols with SS_LOCAL scope
        in a dynamic executable.
        * hppa-tdep.c (find_proc_framesize): Sanely handle the case
        where we are unable to find the minimal symbol for the given
        PC value.


Index: somread.c
===================================================================
RCS file: /cvs/src/src/gdb/somread.c,v
retrieving revision 1.14
diff -c -3 -p -r1.14 somread.c
*** somread.c	2002/02/04 11:55:35	1.14
--- somread.c	2002/03/27 00:17:22
*************** som_symtab_read (bfd *abfd, struct objfi
*** 117,136 ****
       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
!    */
    dynamic = (text_offset != 0);
  
    endbufp = buf + number_of_symbols;
--- 117,129 ----
       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.
! 
!      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;
*************** som_symtab_read (bfd *abfd, struct objfi
*** 240,252 ****
  
  	    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;
  	      bufp->symbol_value += text_offset;
  	      bufp->symbol_value = SMASH_TEXT_ADDRESS (bufp->symbol_value);
  	      break;
--- 233,243 ----
  
  	    case ST_ENTRY:
  	      symname = bufp->name.n_strx + stringtab;
! 	      /* 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;
Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.23
diff -c -3 -p -r1.23 hppa-tdep.c
*** hppa-tdep.c	2002/03/06 06:28:33	1.23
--- hppa-tdep.c	2002/03/27 00:17:25
*************** find_proc_framesize (CORE_ADDR pc)
*** 747,753 ****
  
    /* If Save_SP is set, and we're not in an interrupt or signal caller,
       then we have a frame pointer.  Use it.  */
!   if (u->Save_SP && !pc_in_interrupt_handler (pc)
        && !IN_SIGTRAMP (pc, SYMBOL_NAME (msym_us)))
      return -1;
  
--- 747,755 ----
  
    /* If Save_SP is set, and we're not in an interrupt or signal caller,
       then we have a frame pointer.  Use it.  */
!   if (u->Save_SP
!       && !pc_in_interrupt_handler (pc)
!       && msym_us
        && !IN_SIGTRAMP (pc, SYMBOL_NAME (msym_us)))
      return -1;
  




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]