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

[Daniel Jacobowitz <drow@mvista.com>]

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