This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: msym->info is wack
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 21 Aug 2003 18:49:49 -0400
- Subject: Re: msym->info is wack
- References: <200308202328.h7KNS3cY014321@duracef.shout.net>
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