This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] language hooks for lookup_symbol
David Carlton writes:
> On Mon, 19 May 2003 11:19:50 -0400, Elena Zannoni <ezannoni@redhat.com> said:
>
> > 1. check in the if0 elimination by itself, then the deletion of
> > static_block parameter and teh addition of the block_static_bloc
> > function. After that check in the rest (which is really the big change).
>
> Will do.
>
> > 2. I think that instead of: int la_lookup_symbol_this; We can just
> > have the new field be a function pointer to NULL or to the
> > value_of_this function itself. This function itself can be split
> > in 2, one for objc and one for c++.
>
> That makes sense. I'll also add a FIXME comment saying that we should
> audit all existing languages to make sure that the field is set
> properly.
>
> > 3. move the comments as well, instead of deleting them.
>
> I assume you're referring to these comments?
>
> - /* NOTE: carlton/2002-12-05: There is a question as to whether or
> - not it would be appropriate to search the current global block
> - here as well. (That's what this code used to do before the
> - is_a_field_of_this check was moved up.) On the one hand, it's
> - redundant with the lookup_symbol_aux_symtabs search that happens
> - next. On the other hand, if decode_line_1 is passed an argument
> - like filename:var, then the user presumably wants 'var' to be
> - searched for in filename. On the third hand, there shouldn't be
> - multiple global variables all of which are named 'var', and it's
> - not like decode_line_1 has ever restricted its search to only
> - global variables in a single filename. All in all, only
> - searching the static block here seems best: it's correct and it's
> - cleanest. */
> -
> - /* NOTE: carlton/2002-12-05: There's also a possible performance
> - issue here: if you usually search for global symbols in the
> - current file, then it would be slightly better to search the
> - current global block before searching all the symtabs. But there
> - are other factors that have a much greater effect on performance
> - than that one, so I don't think we should worry about that for
> - now. */
> -
>
> The reason why I was planning to delete them is because they don't
> make a lot of sense after this latest reorganization (since the "this
> code" and the "is_a_field_of_this" mention wouldn't refer to the
> function in question) and because I'm no longer bothered by the qualms
> that led me to write the comments in the first place. But if you want
> me to keep them, I will (adding another note that they've been moved).
If it makes more sense, just rephrase them as you see appropriate.
elena
>
> David Carlton
> carlton@math.stanford.edu