Re: [patch] Do not add partial_symbol again and again to the list

[Daniel Jacobowitz <drow@false.org>]

On Wed, Feb 13, 2008 at 12:22:57AM -0500, Aleksandar Ristovski wrote:
> 3. lookup_partial_symbol
> Function looks up global or static list of objfile, but only subset of it
> determined by partial symtab's offset and number of symbols. Returns partial
> symbol found. This function is always called from a loop through all partial
> symtabs (this fact is important).

Ah!  That's the part I didn't understand before.

I was worried about the construct tested in scope.exp, "print
'scope0.c'::filelocal".  But it uses full symtabs, not partial
symtabs.

> 2008-02-12  Aleksandar Ristovski  <aristovski@qnx.com>
>
> 	* bcache.c (bcache_data): Call bcache_added function.
> 	(bcache_added): New function name. Body of function bcache_data
> 	is used here with the addition of 'added' argument. The argument
> 	is optional and if specified, bcache_added returns 1 if the data
> 	was added and 0 if it was found in the hash.

Whenever you find yourself writing this sort of explanation in the
changelog, it's a sign that you should have a shorter changelog entry
and a long comment in the source code.  Please move the explanation to
bcache.h.

> 	* symfile.c (add_psymbol_to_bcache): New helper function, takes part of
> 	work from add_psymbol_to_list - initialises partial symbol and stashes
> 	it in objfile's cache.
> 	(append_psymbol_to_list): New helper function, takes other part of
> 	work from add_psymbol_to_list - adds partial symbol to the given list.
> 	(add_psymbol_to_list): Call helper functions instead of doing work
> 	here. Functionally, the function hasn't changed.
> 	(add_psymbol_to_global_list): New function, adds partial symbol to
> 	global list and does it only once per objfile.

Same thing for these.

> +const void *
> +bcache (const void *addr, int length, struct bcache *bcache)
> +{
> +  return bcache_data (addr, length, bcache);
> +}
> +
> +void *
> +bcache_added (const void *addr, int length, struct bcache *bcache, 
> +		   int *added)

It should return a const pointer, like bcache.  Also the indentation
on the second line is too deep.

>      case DW_TAG_namespace:
> -      add_psymbol_to_list (actual_name, strlen (actual_name),
> +      add_psymbol_to_global_list (actual_name, strlen (actual_name),
>  			   VAR_DOMAIN, LOC_TYPEDEF,
> -			   &objfile->global_psymbols,
>  			   0, (CORE_ADDR) 0, cu->language, objfile);

Please adjust indentation on the subsequent lines, since the open
paren moved over.

>        if (cu->language == language_cplus
>            || cu->language == language_java
>            || cu->language == language_ada)
>  	{
>  	  /* For C++ and Java, these implicitly act as typedefs as well. */
> -	  add_psymbol_to_list (actual_name, strlen (actual_name),
> -			       VAR_DOMAIN, LOC_TYPEDEF,
> -			       &objfile->global_psymbols,
> -			       0, (CORE_ADDR) 0, cu->language, objfile);
> +	  add_psymbol_to_global_list (actual_name, strlen (actual_name),
> +				      VAR_DOMAIN, LOC_TYPEDEF,
> +				      0, (CORE_ADDR) 0, cu->language, objfile);
>  	}

You've deleted this bit in your other patch fortunately :-)

>      case DW_TAG_enumerator:
> -      add_psymbol_to_list (actual_name, strlen (actual_name),
> +      if (cu->language == language_cplus
> +	  || cu->language == language_java)
> +	add_psymbol_to_global_list (actual_name, strlen (actual_name),
> +				    VAR_DOMAIN, LOC_CONST,
> +				    0, (CORE_ADDR) 0, cu->language, objfile);

This part I don't understand.  Why does the behavior of enumerators
depend on the language?  The logic for finding them during lookup is
the same.

In fact, if lookup_partial_symbol will never find a global symbol
with an identical name why do we need them for any duplicated symbol,
even legitimately duplicated things like static functions?  Well,
the check in cp-support.c is one reason for functions.  And I can
imagine other valid reasons in the future.  So functions are special.
But for things other than functions.

-- 
Daniel Jacobowitz
CodeSourcery