Interactions of symbol-lookup with language

David Carlton
Mon Nov 10 17:07:00 GMT 2003

On Sat, 8 Nov 2003 14:55:19 -0800, "Paul N. Hilfinger"
<> 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

* 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

More information about the Gdb-patches mailing list