From: David Carlton <carlton@kealia.com>
To: Paul Hilfinger <hilfingr@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC] Proposed changes in symbol-handling for Ada
Date: Wed, 21 Jan 2004 16:49:00 -0000 [thread overview]
Message-ID: <yf2broxfdr3.fsf@hawaii.kealia.com> (raw)
In-Reply-To: <20040121112215.AE278F2810@nile.gnat.com> (Paul Hilfinger's message of "Wed, 21 Jan 2004 06:22:15 -0500 (EST)")
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
next prev parent reply other threads:[~2004-01-21 16:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-08 22:55 Interactions of symbol-lookup with language Paul N. Hilfinger
2003-11-10 17:07 ` David Carlton
2004-01-20 10:16 ` [RFC] Proposed changes in symbol-handling for Ada Paul Hilfinger
2004-01-20 15:01 ` Daniel Jacobowitz
2004-01-21 10:55 ` Paul Hilfinger
2004-01-21 15:19 ` Daniel Jacobowitz
2004-01-23 21:08 ` Andrew Cagney
2004-01-20 23:05 ` David Carlton
2004-01-21 11:22 ` Paul Hilfinger
2004-01-21 16:49 ` David Carlton [this message]
2004-01-21 18:50 ` Daniel Jacobowitz
2003-11-11 1:23 ` Interactions of symbol-lookup with language Elena Zannoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yf2broxfdr3.fsf@hawaii.kealia.com \
--to=carlton@kealia.com \
--cc=gdb-patches@sources.redhat.com \
--cc=hilfingr@gnat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox