Interactions of symbol-lookup with language

Interactions of symbol-lookup with language

[Paul N. Hilfinger]

David,

The symbol-lookup facilities are now organized to adapt themselves to
the current language.  We've encountered some problems with this.  

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.  

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".  

In any case, we'd welcome your (and other maintainers') comments.

Paul Hilfinger
ACT, Inc.

Re: Interactions of symbol-lookup with language

[David Carlton]

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

[RFC] Proposed changes in symbol-handling for Ada

[Paul Hilfinger]

David,

I'd appreciate your comments on the following approach to handling the
... um ... difference of opinion between the Ada world and everyone else
regarding symbols.  We've briefly discussed it before; now I'd like to get
specific.

We decided years ago NOT to store demangled names, considering it an
unnecessary waste of space (some ACT customers have very large symbol tables)
and start-up time.  Instead we MANGLE names that are searched for and then
look those up.  In our own sources, we've added a level of indirection to
minimize the effect on the rest of GDB.  It's worked out well, and we've 
experienced very few maintenance problems with this approach (aside, 
of course, from a SMALL amount of fuss to adapt your major re-organization
of the symbol stuff (:->)).  

Basically, we found it sufficient to introduce some additional macros in 
symtab.h: 

+/* Macro that returns the name to be used when sorting and searching symbols. 
+   In  C++, Chill, and Java, we search for the demangled form of a name,
+   and so sort symbols accordingly.  In Ada, however, we search by mangled
+   name. */
+#define SYMBOL_SEARCH_NAME(symbol)					 \
+   (SYMBOL_LANGUAGE (symbol) == language_ada 				 \
+    ? SYMBOL_LINKAGE_NAME (symbol)					 \
+    : SYMBOL_NATURAL_NAME (symbol))
+
+/* Analogous to SYMBOL_MATCHES_NATURAL_NAME, but uses the search
+   name. */
+#define SYMBOL_MATCHES_SEARCH_NAME(symbol, name)			\
+  (strcmp_iw (SYMBOL_SEARCH_NAME (symbol), (name)) == 0)
+
+/* For languages that do not demangle or that do not do searches by 
+   demangled name, NULL.  Otherwise, the demangled name. */
+#define SYMBOL_DEMANGLED_SEARCH_NAME(symbol)				 \
+   (SYMBOL_LANGUAGE (symbol) == language_ada 				 \
+    ? NULL								 \
+    : SYMBOL_DEMANGLED_NAME (symbol))
+

We then use these in place of SYMBOL_DEMANGLED_NAME, SYMBOL_NATURAL_NAME,
etc. in several places.   More details are in the patch below

I'd appreciate your comments before attempting to fill this out into an
offical patch.  Thanks.

Paul Hilfinger 



Index: current-public.41/gdb/defs.h
--- current-public.41/gdb/defs.h Sun, 04 Jan 2004 17:51:24 -0800 hilfingr (GdbPub/h/12_defs.h 1.1.1.5.2.1.1.2.1.1.1.1.1.1.1.1.2.1 644)
+++ submit.29/gdb/defs.h Thu, 15 Jan 2004 03:02:36 -0800 hilfingr (GdbPub/h/12_defs.h 1.1.1.5.2.1.1.2.1.1.1.1.1.1.1.1.2.1.1.1 644)
@@ -223,6 +223,7 @@ enum language
     language_asm,		/* Assembly language */
     language_scm,    		/* Scheme / Guile */
     language_pascal,		/* Pascal */
+    language_ada,		/* Ada */
     language_minimal		/* All other languages, minimal support only */
   };
 
Index: current-public.41/gdb/minsyms.c
--- current-public.41/gdb/minsyms.c Wed, 19 Nov 2003 00:01:38 -0800 hilfingr (GdbPub/j/4_minsyms.c 1.1.1.3.1.1.1.1.1.1.1.1.1.1 644)
+++ submit.29/gdb/minsyms.c Tue, 20 Jan 2004 00:56:34 -0800 hilfingr (GdbPub/j/4_minsyms.c 1.1.1.3.1.1.1.1.1.1.1.1.1.1.2.1 644)
@@ -785,7 +785,7 @@ build_minimal_symbol_hash_tables (struct
       add_minsym_to_hash_table (msym, objfile->msymbol_hash);
 
       msym->demangled_hash_next = 0;
-      if (SYMBOL_DEMANGLED_NAME (msym) != NULL)
+      if (SYMBOL_DEMANGLED_SEARCH_NAME (msym) != NULL)
 	add_minsym_to_demangled_hash_table (msym,
                                             objfile->msymbol_demangled_hash);
     }
Index: current-public.41/gdb/symfile.c
--- current-public.41/gdb/symfile.c Sat, 13 Dec 2003 03:27:23 -0800 hilfingr (GdbPub/k/48_symfile.c 1.1.1.7.1.1.1.2.1.1.1.1.1.1.1.1.1.1 644)
+++ submit.29/gdb/symfile.c Tue, 20 Jan 2004 00:56:34 -0800 hilfingr (GdbPub/k/48_symfile.c 1.1.1.7.1.1.1.2.1.1.1.1.1.1.1.1.1.1.2.1 644)
@@ -210,7 +211,7 @@ compare_symbols (const void *s1p, const 
 
   s1 = (struct symbol **) s1p;
   s2 = (struct symbol **) s2p;
-  return (strcmp (SYMBOL_NATURAL_NAME (*s1), SYMBOL_NATURAL_NAME (*s2)));
+  return (strcmp (SYMBOL_SEARCH_NAME (*s1), SYMBOL_SEARCH_NAME (*s2)));
 }
 
 /* This compares two partial symbols by names, using strcmp_iw_ordered
@@ -222,8 +223,8 @@ compare_psymbols (const void *s1p, const
   struct partial_symbol *const *s1 = s1p;
   struct partial_symbol *const *s2 = s2p;
 
-  return strcmp_iw_ordered (SYMBOL_NATURAL_NAME (*s1),
-			    SYMBOL_NATURAL_NAME (*s2));
+  return strcmp_iw_ordered (SYMBOL_SEARCH_NAME (*s1),
+			    SYMBOL_SEARCH_NAME (*s2));
 }
 
 void
Index: current-public.41/gdb/symtab.c
--- current-public.41/gdb/symtab.c Sun, 04 Jan 2004 17:51:24 -0800 hilfingr (GdbPub/k/50_symtab.c 1.1.1.4.1.1.1.1.1.1.1.1.1.1.2.1 644)
+++ submit.29/gdb/symtab.c Thu, 15 Jan 2004 03:02:36 -0800 hilfingr (GdbPub/k/50_symtab.c 1.1.1.4.1.1.1.1.1.1.1.1.1.1.2.1.1.1 644)
@@ -54,6 +54,7 @@
 #include "gdb_stat.h"
 #include <ctype.h>
 #include "cp-abi.h"
+#include "ada-lang.h"
 
 /* Prototypes for local functions */
 
@@ -639,6 +640,10 @@ symbol_natural_name (const struct genera
     {
       return gsymbol->language_specific.cplus_specific.demangled_name;
     }
+  else if (gsymbol->language == language_ada)
+    {
+      return ada_demangle (gsymbol->name);
+    }
   else
     {
       return gsymbol->name;
@@ -654,7 +659,10 @@ symbol_demangled_name (struct general_sy
       || gsymbol->language == language_java
       || gsymbol->language == language_objc)
     return gsymbol->language_specific.cplus_specific.demangled_name;
-
+  else if (gsymbol->language == language_ada)
+    {
+      return ada_demangle (gsymbol->name);
+    }
   else 
     return NULL;
 }
@@ -1432,7 +1462,7 @@ lookup_partial_symbol (struct partial_sy
 	    {
 	      do_linear_search = 1;
 	    }
-	  if (strcmp_iw_ordered (SYMBOL_NATURAL_NAME (*center), name) >= 0)
+	  if (strcmp_iw_ordered (SYMBOL_SEARCH_NAME (*center), name) >= 0)
 	    {
 	      top = center;
 	    }
@@ -1447,7 +1477,7 @@ lookup_partial_symbol (struct partial_sy
       while (top <= real_top
 	     && (linkage_name != NULL
 		 ? strcmp (SYMBOL_LINKAGE_NAME (*top), linkage_name) == 0
-		 : SYMBOL_MATCHES_NATURAL_NAME (*top,name)))
+		 : SYMBOL_MATCHES_SEARCH_NAME (*top,name)))
 	{
 	  if (SYMBOL_DOMAIN (*top) == domain)
 	    {
@@ -1468,7 +1498,7 @@ lookup_partial_symbol (struct partial_sy
 	    {
 	      if (linkage_name != NULL
 		  ? strcmp (SYMBOL_LINKAGE_NAME (*psym), linkage_name) == 0
-		  : SYMBOL_MATCHES_NATURAL_NAME (*psym, name))
+		  : SYMBOL_MATCHES_SEARCH_NAME (*psym, name))
 		{
 		  return (*psym);
 		}
Index: current-public.41/gdb/symtab.h
--- current-public.41/gdb/symtab.h Wed, 19 Nov 2003 00:01:38 -0800 hilfingr (GdbPub/l/2_symtab.h 1.1.1.5.1.1.1.1.1.1.1.1.1.1 644)
+++ submit.29/gdb/symtab.h Thu, 15 Jan 2004 03:02:36 -0800 hilfingr (GdbPub/l/2_symtab.h 1.1.1.5.1.1.1.1.1.1.1.1.1.1.2.1 644)
@@ -258,6 +260,27 @@ extern char *symbol_demangled_name (stru
 #define SYMBOL_MATCHES_NATURAL_NAME(symbol, name)			\
   (strcmp_iw (SYMBOL_NATURAL_NAME (symbol), (name)) == 0)
 
+/* Macro that returns the name to be used when sorting and searching symbols. 
+   In  C++, Chill, and Java, we search for the demangled form of a name,
+   and so sort symbols accordingly.  In Ada, however, we search by mangled
+   name. */
+#define SYMBOL_SEARCH_NAME(symbol)					 \
+   (SYMBOL_LANGUAGE (symbol) == language_ada 				 \
+    ? SYMBOL_LINKAGE_NAME (symbol)					 \
+    : SYMBOL_NATURAL_NAME (symbol))
+
+/* Analogous to SYMBOL_MATCHES_NATURAL_NAME, but uses the search
+   name. */
+#define SYMBOL_MATCHES_SEARCH_NAME(symbol, name)			\
+  (strcmp_iw (SYMBOL_SEARCH_NAME (symbol), (name)) == 0)
+
+/* For languages that do not demangle or that do not do searches by 
+   demangled name, NULL.  Otherwise, the demangled name. */
+#define SYMBOL_DEMANGLED_SEARCH_NAME(symbol)				 \
+   (SYMBOL_LANGUAGE (symbol) == language_ada 				 \
+    ? NULL								 \
+    : SYMBOL_DEMANGLED_NAME (symbol))
+
 /* Classification types for a minimal symbol.  These should be taken as
    "advisory only", since if gdb can't easily figure out a
    classification it simply selects mst_unknown.  It may also have to
Index: current-public.41/gdb/dictionary.c
--- current-public.41/gdb/dictionary.c Tue, 17 Jun 2003 02:41:56 -0700 hilfingr (GdbPub/L/b/35_dictionary 1.1 644)
+++ submit.29/gdb/dictionary.c Tue, 20 Jan 2004 00:56:34 -0800 hilfingr (GdbPub/L/b/35_dictionary 1.1.3.1 644)
@@ -636,7 +636,7 @@ iter_name_first_hashed (const struct dic
        sym = sym->hash_next)
     {
       /* Warning: the order of arguments to strcmp_iw matters!  */
-      if (strcmp_iw (SYMBOL_NATURAL_NAME (sym), name) == 0)
+      if (strcmp_iw (SYMBOL_SEARCH_NAME (sym), name) == 0)
 	{
 	  break;
 	}
@@ -656,7 +656,7 @@ iter_name_next_hashed (const char *name,
        next != NULL;
        next = next->hash_next)
     {
-      if (strcmp_iw (SYMBOL_NATURAL_NAME (next), name) == 0)
+      if (strcmp_iw (SYMBOL_SEARCH_NAME (next), name) == 0)
 	break;
     }
 
@@ -674,7 +674,7 @@ insert_symbol_hashed (struct dictionary 
   unsigned int hash_index;
   struct symbol **buckets = DICT_HASHED_BUCKETS (dict);
 
-  hash_index = (msymbol_hash_iw (SYMBOL_NATURAL_NAME (sym))
+  hash_index = (msymbol_hash_iw (SYMBOL_SEARCH_NAME (sym))
 		% DICT_HASHED_NBUCKETS (dict));
   sym->hash_next = buckets[hash_index];
   buckets[hash_index] = sym;
@@ -789,7 +789,7 @@ iter_name_next_linear (const char *name,
   for (i = DICT_ITERATOR_INDEX (iterator) + 1; i < nsyms; ++i)
     {
       sym = DICT_LINEAR_SYM (dict, i);
-      if (strcmp_iw (SYMBOL_NATURAL_NAME (sym), name) == 0)
+      if (strcmp_iw (SYMBOL_SEARCH_NAME (sym), name) == 0)
 	{
 	  retval = sym;
 	  break;

Re: [RFC] Proposed changes in symbol-handling for Ada

[Daniel Jacobowitz]

On Tue, Jan 20, 2004 at 05:16:13AM -0500, Paul Hilfinger wrote:
> 
> 
> David,
> 
> I'd appreciate your comments on the following approach to handling the
> ... um ... difference of opinion between the Ada world and everyone else
> regarding symbols.  We've briefly discussed it before; now I'd like to get
> specific.
> 
> We decided years ago NOT to store demangled names, considering it an
> unnecessary waste of space (some ACT customers have very large symbol tables)
> and start-up time.  Instead we MANGLE names that are searched for and then
> look those up.  In our own sources, we've added a level of indirection to
> minimize the effect on the rest of GDB.  It's worked out well, and we've 
> experienced very few maintenance problems with this approach (aside, 
> of course, from a SMALL amount of fuss to adapt your major re-organization
> of the symbol stuff (:->)).  
> 
> Basically, we found it sufficient to introduce some additional macros in 
> symtab.h: 
> 
> +/* Macro that returns the name to be used when sorting and searching symbols. 
> +   In  C++, Chill, and Java, we search for the demangled form of a name,
> +   and so sort symbols accordingly.  In Ada, however, we search by mangled
> +   name. */
> +#define SYMBOL_SEARCH_NAME(symbol)					 \
> +   (SYMBOL_LANGUAGE (symbol) == language_ada 				 \
> +    ? SYMBOL_LINKAGE_NAME (symbol)					 \
> +    : SYMBOL_NATURAL_NAME (symbol))

Hi Paul,

I'd like to get your opinions on another change I've been considering,
first.  It may turn out to be completely unsuitable for Ada, better to
know now than later :)

Rather than demangling at startup, we ask each mangled name for a base
identifier.  This can be done reasonably efficiently - I hope - I
haven't performed measurements yet.  Then, when we search for a symbol,
we wildcard for the basename.  We demangle everything with that
basename.  If you do a search that doesn't know the basename you
have to un-lazy all symbols, of course, but I don't think that's much
of a change.

This would provide, from my undersanding, a small simplification versus
the Ada approach and a solid speedup for the non-Ada approach.

Does Ada have:
 - the concept of a "basename" for each mangled name
     For C++, this would be foo::bar::baz() -> baz, and the basename is
     always stored within the mangled name so can be represented as an
     offset and length.  For Java, I think this is true except for
     escape sequences.  I believe there are fixed rules about what
     characters get escaped, so we can do that to symbols we search for
     before looking for the basename.
 - Reasonably unique (i.e. user-choosable) basenames.  If every package
   (or whatever they are in ada) has a method with the same basename,
   then this scheme obviously won't work.
 - Any other problems?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Proposed changes in symbol-handling for Ada

[Paul Hilfinger]

> Rather than demangling at startup, we ask each mangled name for a base
> identifier.  This can be done reasonably efficiently - I hope - I
> haven't performed measurements yet.  Then, when we search for a symbol,
> we wildcard for the basename.  We demangle everything with that
> basename.  If you do a search that doesn't know the basename you
> have to un-lazy all symbols, of course, but I don't think that's much
> of a change.

Daniel,

At first blush, this sounds like a great idea (at least until someone
introduces a mangling scheme in which the basename is not a
substring).  The basename situation for Ada is essentially the same as you
describe for C++.

As you may know, the current Ada lookup machinery is separate from (and 
partially duplicative of) the usual lookup machinery.  There are two
reasons for this:

1. We actually WANT to be able to match on base name alone if the user
   supplies just a base name.

2. We don't include parameter types in mangled names: instead, our
   basic lookup routine returns a list of all matches, from which we select
   by parameter type or, if that doesn't work, by giving the user a choice.

3. Three; there are three reasons:  we don't store demangled names.

So, your proposal takes care of 3.  If we could persuade you to

A. Provide a mode in which you search for the base name (i.e, return 
   the results of your preliminary sift for base names, skipping the
   comparison against full demangled name), and

B. Provide a mode in which you return ALL matches for a name.

... why we could clean up all that nasty duplication in the ada-* files and
join the civilized world.  

>  - Reasonably unique (i.e. user-choosable) basenames.  If every package
>    (or whatever they are in ada) has a method with the same basename,
>    then this scheme obviously won't work.

"Package" is right.  No, this should not be a particular problem.  

Paul

Re: [RFC] Proposed changes in symbol-handling for Ada

[Daniel Jacobowitz]

On Wed, Jan 21, 2004 at 05:55:10AM -0500, Paul Hilfinger wrote:
> 
> > Rather than demangling at startup, we ask each mangled name for a base
> > identifier.  This can be done reasonably efficiently - I hope - I
> > haven't performed measurements yet.  Then, when we search for a symbol,
> > we wildcard for the basename.  We demangle everything with that
> > basename.  If you do a search that doesn't know the basename you
> > have to un-lazy all symbols, of course, but I don't think that's much
> > of a change.
> 
> Daniel,
> 
> At first blush, this sounds like a great idea (at least until someone
> introduces a mangling scheme in which the basename is not a
> substring).  The basename situation for Ada is essentially the same as you
> describe for C++.
> 
> As you may know, the current Ada lookup machinery is separate from (and 
> partially duplicative of) the usual lookup machinery.  There are two
> reasons for this:
> 
> 1. We actually WANT to be able to match on base name alone if the user
>    supplies just a base name.
> 
> 2. We don't include parameter types in mangled names: instead, our
>    basic lookup routine returns a list of all matches, from which we select
>    by parameter type or, if that doesn't work, by giving the user a choice.
> 
> 3. Three; there are three reasons:  we don't store demangled names.
> 
> So, your proposal takes care of 3.  If we could persuade you to
> 
> A. Provide a mode in which you search for the base name (i.e, return 
>    the results of your preliminary sift for base names, skipping the
>    comparison against full demangled name), and
> 
> B. Provide a mode in which you return ALL matches for a name.
> 
> ... why we could clean up all that nasty duplication in the ada-* files and
> join the civilized world.  

OK.  (B) has always been on my todo list; C++ would benefit from it
also.  (A) will require increasing the size of the symbol (because 
I had been planning to overlap the basename information with the
demangled name information using a union, and store the two sets
separately), but I think it's worthwhile.

No promises on timeline, since I'm working on several other projects
right now, but I'll try to pull this together.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] Proposed changes in symbol-handling for Ada

[Andrew Cagney]

>> 2. We don't include parameter types in mangled names: instead, our
>>    basic lookup routine returns a list of all matches, from which we select
>>    by parameter type or, if that doesn't work, by giving the user a choice.

Isn't this search mechanism required by all languages with overloaded 
methods?

Paul, BTW, look at: The symbol auxilary.
http://sources.redhat.com/ml/gdb/2003-04/msg00017.html

With a per-symbol method, requests for the extra info could be handled 
on-demand (and then added to the symbol aux) without bloating the symbol 
table.

>> 3. Three; there are three reasons:  we don't store demangled names.
>> 
>> So, your proposal takes care of 3.  If we could persuade you to
>> 
>> A. Provide a mode in which you search for the base name (i.e, return 
>>    the results of your preliminary sift for base names, skipping the
>>    comparison against full demangled name), and
>> 
>> B. Provide a mode in which you return ALL matches for a name.
>> 
>> ... why we could clean up all that nasty duplication in the ada-* files and
>> join the civilized world.  
> 
> 
> OK.  (B) has always been on my todo list; C++ would benefit from it
> also.  (A) will require increasing the size of the symbol (because 
> I had been planning to overlap the basename information with the
> demangled name information using a union, and store the two sets
> separately), but I think it's worthwhile.
> 
> No promises on timeline, since I'm working on several other projects
> right now, but I'll try to pull this together.
> 
> -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 

Re: [RFC] Proposed changes in symbol-handling for Ada

[David Carlton]

On Tue, 20 Jan 2004 05:16:13 -0500 (EST), Paul Hilfinger <hilfingr@gnat.com> said:

> Basically, we found it sufficient to introduce some additional macros in 
> symtab.h: 

> +#define SYMBOL_SEARCH_NAME(symbol)					 \
> +#define SYMBOL_MATCHES_SEARCH_NAME(symbol, name)			\
> +#define SYMBOL_DEMANGLED_SEARCH_NAME(symbol)				 \

These don't seem unreasonable to me, given your desires.  If I were a
symtab maintainer, I would ask for measurements to see how much
time/memory doing things your way saves you, but I'm willing to
imagine that it really does help you.  Given that, my main worry is:

> +  else if (gsymbol->language == language_ada)
> +    {
> +      return ada_demangle (gsymbol->name);
> +    }

It used to be the case that the return value of
SYMBOL_{NATURAL,DEMANGLED,PRINT}_NAME had a lifetime that always
lasted as long as the symbol in question; your proposal would mean
that that would no longer be true.  And changing that assumption makes
me nervous.

I'm not sure what to do about that.  Choices that come to mind are:

1) Have the SYMBOL_DEMANGLED_NAME of Ada symbols always be NULL, and
   the SYMBOL_NATURAL_NAME be the mangled name.  In which case, there's
   no need for the search name stuff, but it makes it harder for Ada
   code to use, say, output code in other portions of GDB.

2) Not allow callers to assume that the output of SYMBOL_NATURAL_NAME
   and friends lasts for very long.  Which is a fragile assumption to
   make, and violations of it will be hard to find.

3) Have Ada symbols save the demangled names of symbols after being
   forced to demangle them.  This could cause a memory increase if you
   for some reason have to demangle lots of names.

I think I would vote for option 3 - after all, one point of your
proposal is that you _don't_ have to demangle lots of names.  And, if
you did have to do that once for some reason, then probably there's a
good chance that you'd have to do it a second time, at which point
caching becomes a time win, if not a space win.

(Hmm: where would you allocate the cached name from?  You can't get at
the appropriate obstack from the symbol, can you?  Sigh.  I do not
enjoy worrying about memory management when programming in C.)

David Carlton
carlton@kealia.com

Re: [RFC] Proposed changes in symbol-handling for Ada

[Paul Hilfinger]

> 3) Have Ada symbols save the demangled names of symbols after being
>    forced to demangle them.  This could cause a memory increase if you
>    for some reason have to demangle lots of names.

That sounds entirely reasonable.  

> (Hmm: where would you allocate the cached name from?  You can't get at
> the appropriate obstack from the symbol, can you?

Actually, the only true problem here is that the obvious way of
answering this question---adding to the language-specific union a new
entry containing an obstack* / char* union plus a flag---increases the
size of a symbol (logically it doesn't have to, but C layout and
alignment rules apparently add some padding).  To avoid increasing its
size, there is the aesthetically distateful option of adding a flag
byte AFTER the language-specific field; or perhaps we could call it
a union tag.  Harumph.

> Sigh.  I do not
> enjoy worrying about memory management when programming in C.)

You don't?  Good grief, man, what has happened to your sense of
adventure, your thirst for danger?

Paul

Re: [RFC] Proposed changes in symbol-handling for Ada

[David Carlton]

On Wed, 21 Jan 2004 06:22:15 -0500 (EST), Paul Hilfinger <hilfingr@gnat.com> said:

>> 3) Have Ada symbols save the demangled names of symbols after being
>> forced to demangle them.  This could cause a memory increase if you
>> for some reason have to demangle lots of names.

> That sounds entirely reasonable.  

>> (Hmm: where would you allocate the cached name from?  You can't get at
>> the appropriate obstack from the symbol, can you?

> Actually, the only true problem here is that the obvious way of
> answering this question---adding to the language-specific union a
> new entry containing an obstack* / char* union plus a
> flag---increases the size of a symbol (logically it doesn't have to,
> but C layout and alignment rules apparently add some padding).  To
> avoid increasing its size, there is the aesthetically distateful
> option of adding a flag byte AFTER the language-specific field; or
> perhaps we could call it a union tag.  Harumph.

Harumph indeed.  I know - we can grab one of the bits of the
obstack*/char* as a tag bit!  (Just joking, folks, just joking.)  Is
there any way to go from a bfd_section to an objfile?  (After all,
presumably the obstack that we'd use is the relevant objfile's
symbol_obstack.)  If that's not possible, we could store an objfile *
in the language-specific union in the Ada case (instead of a char *)
and then always retrieve the demangled names from the objfile's
demangled names hashtable, instead of caching it in the symbol.
(Inserting the names there first if they're not there already, of
course.)  That should work.

David Carlton
carlton@kealia.com

Re: [RFC] Proposed changes in symbol-handling for Ada

[Daniel Jacobowitz]

On Wed, Jan 21, 2004 at 08:49:36AM -0800, David Carlton wrote:
> On Wed, 21 Jan 2004 06:22:15 -0500 (EST), Paul Hilfinger <hilfingr@gnat.com> said:
> 
> >> 3) Have Ada symbols save the demangled names of symbols after being
> >> forced to demangle them.  This could cause a memory increase if you
> >> for some reason have to demangle lots of names.
> 
> > That sounds entirely reasonable.  
> 
> >> (Hmm: where would you allocate the cached name from?  You can't get at
> >> the appropriate obstack from the symbol, can you?
> 
> > Actually, the only true problem here is that the obvious way of
> > answering this question---adding to the language-specific union a
> > new entry containing an obstack* / char* union plus a
> > flag---increases the size of a symbol (logically it doesn't have to,
> > but C layout and alignment rules apparently add some padding).  To
> > avoid increasing its size, there is the aesthetically distateful
> > option of adding a flag byte AFTER the language-specific field; or
> > perhaps we could call it a union tag.  Harumph.
> 
> Harumph indeed.  I know - we can grab one of the bits of the
> obstack*/char* as a tag bit!  (Just joking, folks, just joking.)  Is
> there any way to go from a bfd_section to an objfile?  (After all,
> presumably the obstack that we'd use is the relevant objfile's
> symbol_obstack.)  If that's not possible, we could store an objfile *
> in the language-specific union in the Ada case (instead of a char *)
> and then always retrieve the demangled names from the objfile's
> demangled names hashtable, instead of caching it in the symbol.
> (Inserting the names there first if they're not there already, of
> course.)  That should work.

Well, you can go from a bfd_section to a bfd, and search objfiles. 
That's a little ugly though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Interactions of symbol-lookup with language

[Elena Zannoni]

Paul N. Hilfinger writes:
 > 
 > David,
 > 
 > The symbol-lookup facilities are now organized to adapt themselves to
 > the current language.  We've encountered some problems with this.  
 > 
 > 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.  
 > 
 > 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".  
 > 
 > In any case, we'd welcome your (and other maintainers') comments.
 > 
 > Paul Hilfinger
 > ACT, Inc.

Hmmm, this is the same bit of code which was creating problems with
breakpoints in objc. (see Adam's post of a week or so ago). It seems
like a new interface is needed. We have stretched the current one(s)
to its limits.  I'll have to think a bit about this. 

elena