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]

Re: [rfa] delete lookup_symbol_aux_minsyms


David Carlton writes:
 > On Sat, 22 Feb 2003 15:50:11 -0500, Daniel Jacobowitz <drow at mvista dot com> said:
 > > On Sat, Feb 22, 2003 at 11:54:40AM -0800, David Carlton wrote:
 > 
 > >> So what's the conclusion?  Performance considerations don't seem to
 > >> give a clear answer.  So we should go with whatever's cleanest.  My
 > >> recommendation:
 > >> 
 > >> * Delete the 'else' clause: it might cause correctness problems.
 > >> 
 > >> * Comment out the remaining part of lookup_symbol_aux_minsyms: if
 > >> somebody comes up with a situation where we spend lots of time
 > >> searching for functions that aren't in a loaded symtab, we can
 > >> consider uncommenting it and adding it back in.
 > 
 > > I'm pretty sure the answer is "none at all" based on skimming the
 > > code, but what affect does removing lookup_symbol_aux_minsyms have
 > > when looking for something which turns out not to have debugging
 > > info?  lookup_symbol would fail, so it doesn't matter - is that
 > > right?
 > 
 > That's right: lookup_symbol tries to find symbols, so if a function
 > doesn't have debugging info, then lookup_symbol will return NULL
 > (unless we're in some sort of bizarre situation like having a static
 > function elsewhere with the same name), at which point it's the
 > caller's responsibility to call lookup_minimal_symbol if the caller is
 > in a position to deal with minimal symbols instead of symbols.  And
 > lookup_symbol would have returned NULL either before or after my
 > patch: the call to 'find_pc_sect_symtab' would have failed.
 > 
 > > I don't know if I like this comment-out-part-delete-part business;
 > > if we don't want the function, let's kill it.
 > 
 > It's not my first choice, either, but Elena has shown a preference in
 > the past for commenting out code like this instead of deleting it.
 > (C.f. the already commented-out bit in lookup_symbol_aux.)  This seems
 > to me a situation where it's not worth arguing about it.  However, if
 > Elena would rather delete it, I'd be happy to go along with that, too.
 > 
 > David Carlton
 > carlton at math dot stanford dot edu


Actually, I did some gcov on that function last night, running make check,
here is what I got.

About deleting the function. I think I would prefer if we delete the
'else' part first. Then comment out the function.

But I am still not convinced that we should delete it yet.

elena



		static struct symbol *
		lookup_symbol_aux_minsyms (const char *name,
					   const char *mangled_name,
					   const namespace_enum namespace,
					   int *is_a_field_of_this,
					   struct symtab **symtab)
		{
        1442      struct symbol *sym;
		  struct blockvector *bv;
		  const struct block *block;
		  struct minimal_symbol *msymbol;
		  struct symtab *s;
		
        1442      if (namespace == VAR_NAMESPACE)
		    {
        1332          msymbol = lookup_minimal_symbol (name, NULL, NULL);
		
        1332          if (msymbol != NULL)
			{
			  /* OK, we found a minimal symbol in spite of not finding any
			     symbol. There are various possible explanations for
			     this. One possibility is the symbol exists in code not
			     compiled -g. Another possibility is that the 'psymtab'
			     isn't doing its job.  A third possibility, related to #2,
			     is that we were confused by name-mangling. For instance,
			     maybe the psymtab isn't doing its job because it only
			     know about demangled names, but we were given a mangled
			     name...  */
		
			  /* We first use the address in the msymbol to try to locate
			     the appropriate symtab. Note that find_pc_sect_symtab()
			     has a side-effect of doing psymtab-to-symtab expansion,
			     for the found symtab.  */
         329    	  s = find_pc_sect_symtab (SYMBOL_VALUE_ADDRESS (msymbol),
						   SYMBOL_BFD_SECTION (msymbol));
         329    	  if (s != NULL)
			    {
			      /* This is a function which has a symtab for its address.  */
         201    	      bv = BLOCKVECTOR (s);
         201    	      block = BLOCKVECTOR_BLOCK (bv, GLOBAL_BLOCK);
		
			      /* This call used to pass `SYMBOL_NAME (msymbol)' as the
			         `name' argument to lookup_block_symbol.  But the name
			         of a minimal symbol is always mangled, so that seems
			         to be clearly the wrong thing to pass as the
			         unmangled name.  */
         201    	      sym =
				lookup_block_symbol (block, name, mangled_name, namespace);
			      /* We kept static functions in minimal symbol table as well as
			         in static scope. We want to find them in the symbol table. */
         201    	      if (!sym)
				{
          39    		  block = BLOCKVECTOR_BLOCK (bv, STATIC_BLOCK);
          39    		  sym = lookup_block_symbol (block, name,
							     mangled_name, namespace);
         201    		}
		
			      /* NOTE: carlton/2002-12-04: The following comment was
				 taken from a time when two versions of this function
				 were part of the body of lookup_symbol_aux: this
				 comment was taken from the version of the function
				 that was #ifdef HPUXHPPA, and the comment was right
				 before the 'return NULL' part of lookup_symbol_aux.
				 (Hence the "Fall through and return 0" comment.)
				 Elena did some digging into the situation for
				 Fortran, and she reports:
		
				 "I asked around (thanks to Jeff Knaggs), and I think
				 the story for Fortran goes like this:
		
				 "Apparently, in older Fortrans, '_' was not part of
				 the user namespace.  g77 attached a final '_' to
				 procedure names as the exported symbols for linkage
				 (foo_) , but the symbols went in the debug info just
				 like 'foo'. The rationale behind this is not
				 completely clear, and maybe it was done to other
				 symbols as well, not just procedures."  */
		
			      /* If we get here with sym == 0, the symbol was 
			         found in the minimal symbol table
			         but not in the symtab.
			         Fall through and return 0 to use the msymbol 
			         definition of "foo_".
			         (Note that outer code generally follows up a call
			         to this routine with a call to lookup_minimal_symbol(),
			         so a 0 return means we'll just flow into that other routine).
		
			         This happens for Fortran  "foo_" symbols,
			         which are "foo" in the symtab.
		
			         This can also happen if "asm" is used to make a
			         regular symbol but not a debugging symbol, e.g.
			         asm(".globl _main");
			         asm("_main:");
			       */
		
         201    	      if (symtab != NULL && sym != NULL)
         155    		*symtab = s;
         201    	      return fixup_symbol_section (sym, s->objfile);
         128    	    }
         128    	  else if (MSYMBOL_TYPE (msymbol) != mst_text
				   && MSYMBOL_TYPE (msymbol) != mst_file_text
				   && !STREQ (name, SYMBOL_NAME (msymbol)))
			    {
			      /* This is a mangled variable, look it up by its
			         mangled name.  */
           2    	      return lookup_symbol_aux (SYMBOL_NAME (msymbol), mangled_name,
							NULL, namespace, is_a_field_of_this,
           2    					symtab);
         126    	    }
        1129    	}
        1239        }
		
        1239      return NULL;
        1442    }


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