Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol?

Michael Elizabeth Chastain
2003-10-11T18:39:25Z

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