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

Daniel Jacobowitz
2004-01-21T18:50:18Z

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