From: Michael Elizabeth Chastain <mec@shout.net>
To: ac131313@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol?
Date: Sat, 11 Oct 2003 18:39:00 -0000 [thread overview]
Message-ID: <200310111839.h9BIdNm8020908@duracef.shout.net> (raw)
First, ignore the comment in struct minimal_symbol, the comment
is wrong and obsolete.
'msymbol.info' currently has three meanings.
The first meaning is: coffread.c stores a 'storage class' into
msymbol.info. However, no code *ever* reads that back.
gdb 4.17 used to read this information in arm_pc_is_thumb
to decide whether an msym was a Thumb symbol or Arm symbol.
But this mechanism was replaced in gdb 4.18 with
COFF_MAKE_MSYMBOL_SPECIAL.
The first meaning can die as soon as someone can test a coff platform
with a trivial patch to coffread.c.
The second meaning is: dbxread.c stores the size of the msym
in 'msymbol.info'. It does this in case SOFUN_ADDRESS_MAYBE_MISSING
is set, in order to synthesize texthigh for that file.
The third meaning is that arm-tdep.c, m68hc11-tdep.c, mips-tdep.c,
and sh-tdep.c use msymbol.info as a place to store one or two
flag bits.
> Consequently, I'd like to propose that "info" be superseeded by a
> "struct bfd_symbol *" pointer.
I don't quite understand your proposal, because there are three
meanings of "msymbol.info". Which meanings do you want to supersede?
Can you put up a little sample code?
> The consequence will be that, for a time, the minimal symbol table will
> be bigger.
Here are some numbers from some old test run:
msym 0.3 mb
psym 11.9 mb
sym 30.1 mb
mt 8.7 mb # main_type
The msym's are not space critical.
It sucks that msymbol.info is overloaded for three different meanings
(and none of them is a pointer so we get all those nasty casts). Let's
separate it into different fields, and then when the data types are
nice and correct, if we want the space back (which I think we won't),
then we can go for 'union' and bit-field things to get the size back
down.
Andrew, I think what you are saying is that you want to separate
out the data field for meaning #3, and have a separate field in the
minsym. And your new field would be a "struct bfd_symbol *" pointer
instead of the current 1-2 flag bits. That would be fine with me.
Michael C
next reply other threads:[~2003-10-11 18:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-11 18:39 Michael Elizabeth Chastain [this message]
2003-10-11 20:02 ` Andrew Cagney
2003-10-13 20:28 ` Elena Zannoni
-- strict thread matches above, loose matches on Subject: below --
2003-10-14 17:36 Michael Elizabeth Chastain
2003-10-14 20:09 ` Elena Zannoni
2003-10-11 20:44 Michael Elizabeth Chastain
2003-10-11 20:22 Michael Elizabeth Chastain
2003-10-11 20:42 ` Andrew Cagney
2003-10-11 17:16 Andrew Cagney
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=200310111839.h9BIdNm8020908@duracef.shout.net \
--to=mec@shout.net \
--cc=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.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