From: David Carlton <carlton@math.stanford.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFA/symtab: Let search_symbols find exact matches
Date: Mon, 10 Feb 2003 21:15:00 -0000 [thread overview]
Message-ID: <ro1hebbj0ra.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <20030210202506.GA17910@nevyn.them.org>
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
next prev parent reply other threads:[~2003-02-10 21:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-10 16:01 Daniel Jacobowitz
2003-02-10 20:10 ` David Carlton
2003-02-10 20:18 ` David Carlton
2003-02-10 20:25 ` Daniel Jacobowitz
2003-02-10 21:15 ` David Carlton [this message]
2003-02-10 21:17 ` Daniel Jacobowitz
2003-02-20 22:41 ` David Carlton
2003-02-21 14:10 ` Daniel Jacobowitz
2003-02-21 15:27 ` Elena Zannoni
2003-02-21 17:14 ` David Carlton
2003-02-21 17:09 ` David Carlton
2003-02-25 0:35 ` David Carlton
2003-02-21 19:15 ` Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1hebbj0ra.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox