This is the mail archive of the gdb@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]

names of symbols


I've been thinking about what methods symbols should provide for
interacting with their names.  This is longish-term stuff, initially
prompted by Paul's description of what Ada does: I was trying to
figure out if I didn't like it because it was really a bad idea, or
just because of "not invented here" reasons.

I'm coming to the conclusion that C++ will eventually want to be more
flexible in this regard as well.  Right now, we rely on demangled
names too much; those names contain quite a lot of information, and we
should, whenever possible, be getting (and presumably also storing)
that information in a different way.  This might fit into Andrew's
"symbol auxiliary" ideas, too.

Of course, we'll never be able to entirely get away from trying to
parse names: they come as user input, after all.  But this matching is
asymmetric: if a lookup function wants to see if a user-input string
matches a symbol's natural name, then instead of having the lookup
function ask for the symbol's natural name and then do some sort of
comparison function between that name and what the user typed, it
might be better to embed the comparison function within the symbol
itself, so that no natural name has to be computed by the symbol if
there's a better way to do things.  This puts the comparison function
closer to the data that it's dealing with, and gives different
languages more flexibility to implement whatever behavior is useful
for them.

In fact, we already basically do this: we have a macro
SYMBOL_MATCHES_NATURAL_NAME for this purpose.  (Note that strcmp_iw is
already asymmetric, so having a macro like this around is useful to
make sure that you get your arguments in the right order.)  So we
could just, in the future, promote this to a full-fledged function
(albeit with a macro front end, just like SYMBOL_NATURAL_NAME).

Paul: would doing this instead of adding SYMBOL_SEARCH_NAME fit Ada's
needs?  I guess that we'd probably also want to add a SYMBOL_HASH
method as well; are there any other bits that I'm missing?  Of course,
the more data we generate on-demand, the more memory-management
headaches we start running into, but that's a separate story...

David Carlton
carlton@kealia.com


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