Re: msym->info is wack

[Andrew Cagney <ac131313@redhat.com>]

> Here are some notes on msym->info.  I am going to submit a couple
> of patches based on these notes.

Thanks for the reminder.

> === ARM-TDEP.C, M68HC11-TDEP.C, MIPS-TDEP.C, SH-TDEP.C
> 
> These *-tdep.c files use msym->info as a place to store flag bits.
> So, first, they are converting 'void *' to 'long' and back again.

Begs the question, is the field needed -> can bfd provide the info directly?

Arm, MIPS, SH, use it to determine the functions CPU mode.  Thing is, 
libopcodes (in the disassembler) must duplicate that exact same 
heuristic as otherwize the 'objdum -d' won't work.

That leaves m68hc11.  Perhaphs a more lazy approach and a symbol aux can 
be used?

> The straightforward solution is to provide msym->tdep_flags as
> an explicit place for tdep files to store flag bits.  Then they
> can store their bits without nasty casting.

Notice that arm defines/uses:

#define MSYMBOL_SET_SPECIAL(msym)                                       \
         MSYMBOL_INFO (msym) = (char *) (((long) MSYMBOL_INFO (msym))    \
                                         | 0x80000000)

#define MSYMBOL_IS_SPECIAL(msym)                                \
         (((long) MSYMBOL_INFO (msym) & 0x80000000) != 0)

#define MSYMBOL_SIZE(msym)                              \
         ((long) MSYMBOL_INFO (msym) & 0x7fffffff)

i.e., it is doing masking, while dbxread.c defines/uses:

#define MSYMBOL_SIZE(msym) ((long) MSYMBOL_INFO (msym))

i.e., there is no masking.  If Arm sets that top bit, dbxread.c would 
discover a very large size.

Guess that never happens.

Andrew