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] 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


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