Re: Interactions of symbol-lookup with language

David Carlton
2003-11-10T17:07:59Z

On Sat, 8 Nov 2003 14:55:19 -0800, "Paul N. Hilfinger"
<hilfingr@otisco.mckusick.com> said:

> In particular, in decode_line_1, there is a call to find_imps, an
> Objective C function, which in turn calls lookup_symbol. When
> decode_line_1 is called while in Ada mode, this latter lookup_symbol
> acts like an Ada symbol lookup, which makes little sense given that
> find_imps is concerned with Objective C code. We have encountered
> cases where the result is anomalous.

Ugh. I suppose it makes sense that the problem would arise in
decode_line_1, though: by its nature, it often gets invoked to refer
to functions in other files, which might be in other languages.

> Our fix for the moment is simply to put a wrapper around decode_objc
> to force the language to objc temporarily. We are a little
> uncomfortable with submitting this kind of kludge publicly, and
> would prefer something officially blessed. One possibility is to
> have a variant of lookup_symbol that allows one to specify a
> prevailing language for those cases where it matters. We have at
> least one other place where we'd like to "look up a symbol as in C".

That kludge wouldn't bother me too much if it were an isolated thing,
but given that it's occurring more than once, I like your idea of
adding a variant of lookup_symbol that specifies a language. My
suggestions would be:

* The comment before the new function should make it clear that the
'name' argument should be a demangled name. (Assuming, of course,
that that fits all of the places where it's being used; if not, I'd
like to hear about the exceptions.) It's okay for the
implementation to call lookup_symbol (even though that function
would then try to demangle it) - it's just that I've been trying to
figure out which functions take demangled names and which functions
take mangled names, and I don't want new functions to muddy the
waters.

* Don't add in all the arguments from lookup_symbol: just add in the
ones you need. That function has too many arguments as it is, even
though only certain combinations of arguments ever get used; I'd
rather have new functions provide cleaner interfaces. (We can
always add more arguments later if they're needed, after all.)

David Carlton
carlton@kealia.com