This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: msym->info is wack


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]