msym->info is wack
Andrew Cagney
ac131313@redhat.com
Thu Aug 21 22:50:00 GMT 2003
> 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
More information about the Gdb
mailing list