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

[Michael Elizabeth Chastain <mec@shout.net>]

eza> OK, so what you are really saying is that there are in the whole gdb
eza> only a few calls to {prim_}record_minimal_symbol_and_info which have
eza> a non-null info parameter (the 4th one).

Yes, that is true.

I think there are two things we could do to elfread.c:

(1A) Quit abusing msymbol.info to store a size in some of the bits.
     Just create msymbol.size with the proper data type.

(1B) More like Elena says (and maybe Andrew is saying), change
     the actual algorithm to use bfd information.

Perhaps (1A) would be a useful patch to separate out this issue
from the other uses of msymbol.info.  We could do (1B) later.
Or just go straight to (1B).

Over in coffread.c, with the "cs->c_sclass" being stuffed into
msymbol.info, gdb 4.17 (!) used to read it back.  But then that
changed with gdb 4.18.  Again there are two ways to deal with this:

(2A) Data is being written and never read back anywhere, just
     mechanically kill the write.

(2B) Data is being written and never read back anywhere, investigate
     what *should* be happening (if anything).  And it might turn out
     that what *should* happen is the same code should die, after
     someone puts some thought into it.

I have to say, I was a fan of (2A), but now I am not, because if
we just do (2A), then we have nothing to remind us of (2B) later.

eza> Then there are MSYMBOL_IS_SPECIAL, msymbol_is_special, MSYMBOL_IS_RTC,
eza> MSYMBOL_IS_RTI. All of them can just use the bfd symbol instead, and
eza> are only in the tdep files.

Yeah.

eza> So, ok. Makes sense.

Sounds like everybody is converging on a common vision.  Yay.

Michael C