[rfc] lookups with natural/linkage names

[rfc] lookups with natural/linkage names

[David Carlton]

Right now, both lookup_symbol and lookup_minimal_symbol accept either
a linkage name or a natural name as an argument.  This seems to me to
not be very desirable: having spent a lot of time cleaning up the
internals of lookup_symbol (and lookup_partial_symbol, and other
functions) to get rid of bugs related to this confusion, I'd rather
have it as clear as possible within GDB's code when one is expected
and when the other is expected, and have as few functions as possible
that accept both.

My basic attitude is that symbols should normally be accessed via
natural names and minimal symbols should normally be accessed via
linkage names.  (There are exceptions, of course: if you want to find
the symbol associated to a minsym, for example, you'll probably be
doing a symbol search via a linkage name.)  Furthermore, for names
that are generated internally to GDB, we should always know whether
the name is a natural name or a linkage name, so it's safe to use a
lookup function that only accepts one sort of name or the other.

But sometimes we have to deal with user-provided names, which are
usually natural names but might occasionally be linkage names.
Exactly what we should do with those is open to question (which is why
this is an RFC!).  In all situations (I _think_; certainly most of
them) where we look up something from a user-provided name, GDB first
tries to look up a symbol and then, if that fails, tries to look up a
minsym.  So it seems to me that it's a reasonable choice to, when
looking up a symbol from a user-provided name, always assume that it's
a natural name, but when looking up a minsym, to accept either a
natural name or a linkage name.

That leads to the following recommendations:

* Add a function

    struct symbol *lookup_symbol_linkage (const char *name);

  that looks up the symbol whose linkage name is NAME.  It only looks
  up global or static symbols (with preference to the former), and
  only looks up symbols in VAR_DOMAIN; it doesn't apply any
  language-specific rules.  This will, for example, give us a reliable
  way to find the symbol associated to a minsym, no matter how
  complicated C++ lookup rules make things.

* Eventually, once lookup_symbol_linkage is being used wherever it's
  appropriate, have lookup_symbol stop accepting linkage names: only
  allow natural names.

* Provide a function

    struct minimal_symbol *
    lookup_minimal_symbol_linkage_or_natural (const char *name);

  that looks up a minsym via either a natural name or a linkage name.
  (Yes, the name is ugly; on the other hand, we should never blithely
  use this function, so an ungainly but descriptive name isn't such a
  bad idea.)

* Eventually, once lookup_minimal_symbol_linkage_or_natural is being
  used wherever is appropriate, have lookup_minimal_symbol only accept
  linkage names.

I don't believe that there's a need for a version of
lookup_minimal_symbol that only accepts natural names: it is my belief
that the only calls to lookup_minimal_symbol that might want to accept
a natural name are those using user-provide names, where
lookup_minimal_symbol_linkage_or_natural is appropriate.

I've had these implemented on my branch for a few months, and they
seem to work fine.

David Carlton
carlton@bactrian.org

Re: [rfc] lookups with natural/linkage names

[Paul N. Hilfinger]

> * Add a function

>    struct symbol *lookup_symbol_linkage (const char *name);

>  that looks up the symbol whose linkage name is NAME.  It only looks
>  up global or static symbols (with preference to the former), and
>  only looks up symbols in VAR_DOMAIN; it doesn't apply any
>  language-specific rules.  This will, for example, give us a reliable
>  way to find the symbol associated to a minsym, no matter how
>  complicated C++ lookup rules make things.

David,

What exactly is the reasoning that says that such lookups needn't consider
local (or rather non-static/global) symbols?

Paul

Re: [rfc] lookups with natural/linkage names

[Daniel Jacobowitz]

On Sat, May 24, 2003 at 01:11:19AM -0700, Paul N. Hilfinger wrote:
> 
> > * Add a function
> 
> >    struct symbol *lookup_symbol_linkage (const char *name);
> 
> >  that looks up the symbol whose linkage name is NAME.  It only looks
> >  up global or static symbols (with preference to the former), and
> >  only looks up symbols in VAR_DOMAIN; it doesn't apply any
> >  language-specific rules.  This will, for example, give us a reliable
> >  way to find the symbol associated to a minsym, no matter how
> >  complicated C++ lookup rules make things.
> 
> David,
> 
> What exactly is the reasoning that says that such lookups needn't consider
> local (or rather non-static/global) symbols?

Normally, symbols with a linkage name (i.e. that appear in the minsym
table) are only global or static.  Does Ada have an exception to this?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfc] lookups with natural/linkage names

[David Carlton]

On Sat, 24 May 2003 01:11:19 -0700, "Paul N. Hilfinger" <hilfingr@otisco.mckusick.com> said:

>> * Add a function

>> struct symbol *lookup_symbol_linkage (const char *name);

>> that looks up the symbol whose linkage name is NAME.  It only looks
>> up global or static symbols (with preference to the former), and
>> only looks up symbols in VAR_DOMAIN; it doesn't apply any
>> language-specific rules.  This will, for example, give us a
>> reliable way to find the symbol associated to a minsym, no matter
>> how complicated C++ lookup rules make things.

> What exactly is the reasoning that says that such lookups needn't
> consider local (or rather non-static/global) symbols?

Linkage names are intended to support symbols that the linker knows
about.  Those are all global or static, those are all in VAR_DOMAIN.
Basically, the point of this function is to support things like
reliably looking up a symbol associated to a minsym.

Does Ada have exceptions to this?  Does Ada somehow mangle names of
local variables or something?  If so, why, and how is that represented
in the debug info?

David Carlton
carlton@math.stanford.edu

Re: [rfc] lookups with natural/linkage names

[Paul N. Hilfinger]

> > What exactly is the reasoning that says that such lookups needn't consider
> > local (or rather non-static/global) symbols?
> 
> Normally, symbols with a linkage name (i.e. that appear in the minsym
> table) are only global or static.  Does Ada have an exception to this?

Not exactly, but actually I am not specifically talking about Ada here.
The equation

	linkage name == minsym name

worries me a little.  The only alterative names to linkage names are
natural names (I'll ignore print names for now).  Therefore, the only
possible kind of mangled name is a minsym name.

Are nested function names ever mangled?  We seldom consider nested functions,
because they don't occur in official C/C++, but they do occur in GCC's 
extensions (and in Pascal and Ada).  On IRIX, using Dwarf-2, nested function
names do NOT appear in the minimal symbols (whereas on Linux, they do). 
I hope you see why this makes me slightly nervous.

Now, it is true that Ada mangles more stuff (in particular, type names), 
but since we never look up demangled names, this is actually somewhat less
of an issue for us.

Paul Hilfinger

Re: [rfc] lookups with natural/linkage names

[David Carlton]

On Mon, 26 May 2003 03:42:59 -0700, "Paul N. Hilfinger" <hilfingr@otisco.mckusick.com> said:

> Are nested function names ever mangled?  We seldom consider nested
> functions, because they don't occur in official C/C++, but they do
> occur in GCC's extensions (and in Pascal and Ada).  On IRIX, using
> Dwarf-2, nested function names do NOT appear in the minimal symbols
> (whereas on Linux, they do).  I hope you see why this makes me
> slightly nervous.

Eep.  I hadn't thought of that case.

Still, I don't see why there would be a particular reason to mangle
names of nested functions.  The point of mangling is to communicate
rich information about an object over an information channel whose
format is tightly constrained.  But for local objects, you can use the
debug info as the information channel, and its format is very rich.
So information about, say, types of arguments to nested functions can
(and should, in my reading of DWARF 2, though I admit that the
standard is annoyingly vague about names) be transmitted in other
parts of the debug info, not in the name attribute.

Having said that, there's still the question of whether or not GDB
currently depends on getting information from the mangled name.  And
the answer is that, currently, it does that to an extent that is
probably unhealthy.

David Carlton
carlton@math.stanford.edu