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/symtab: Let search_symbols find exact matches


On Mon, 10 Feb 2003 15:25:06 -0500, Daniel Jacobowitz <drow@mvista.com> said:

> There are like a million ways in GDB to find a list of symbols.  Me,
> I think that's a recipe for suffering.  They're all subtly
> different.  I want the same set of symbols considered for overload
> resolution and tab completion, and there's no reason that this
> should be different from the results of "break".  I intend some day
> to condense them all.

Yup.  I'm just nervous about this for a couple of reasons:

1) If functions try to handle too many situations, they get ugly; I'm
   still in recovery from trying to deal with find_overload_match, for
   example.  On the other hand, duplicated code is ugly, too.  And
   we're programming in C, which limits our options.  I don't know how
   to best resolve this tension in this particular case; I doubt I'll
   be thrilled with whatever outcome we end up with.  (Unless cleaning
   this mess takes long enough that we end up porting GDB to C++
   first, though even that would only go so far in this instance.)

2) I don't understand search_symbols yet; it's a lot messier than
   make_symbol_overload_list.  Based on some reading of the code and
   on my experience with cleaning up lookup_symbol_aux, I expect that
   much of that messiness doesn't need to be there.  I'd be happier if
   somebody (you, me, some other foolhardy person who wants to be
   initiated into the mysteries of GDB's symbol-management "logic")
   cleaned up search_symbols first.  That way, we could have an
   informed opinion about the differences between search_symbols and
   make_symbol_overload_list before merging them.  (And I suspect that
   the differences would shrink over the course of that cleanup,
   making the merge easier.)

But, of course, this is just a reflection of my programming style;
different people could reasonably come to a different conclusion on
this matter.

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]