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

Elena Zannoni
2003-10-13T20:28:39Z

Andrew Cagney writes:
>
> > The first meaning can die as soon as someone can test a coff platform
> > with a trivial patch to coffread.c.
> >
> > The second meaning is: dbxread.c stores the size of the msym
> > in 'msymbol.info'. It does this in case SOFUN_ADDRESS_MAYBE_MISSING
> > is set, in order to synthesize texthigh for that file.
> >
> > The third meaning is that arm-tdep.c, m68hc11-tdep.c, mips-tdep.c,
> > and sh-tdep.c use msymbol.info as a place to store one or two
> > flag bits.
>
> The third meaning needs to be refined slightly. MAKE_MSYMBOL_SPECIAL,
> for coff, doesn't yet take a "bfd_symbol", in fact, coffread doesn't
> even use BFD's canonicalize_symtab to read the symbols.
>

Hmm there is arm_coff_make_msymbol_special, but there is also:

2002-01-06 Andrew Cagney <ac131313@redhat.com>

* MAINTAINERS: Note that alpha-dec-osf4.0a, arc-elf, arm-coff,
arm-elf, arm-pe, d30v-elf, fr30-elf, h8300hms, h8500hms,
i960-coff, m32r-elf, m68k-elf, m88k, mcore-elf, mn10200-elf,
ns32k-netbsd, hppa1.1-hp-proelf, v850-elf, vax-dec-vms5.5 and
z8k-coff have not been multi-arched. Update z8k-coff build
status.

2002-01-13 Andrew Cagney <ac131313@redhat.com>

* MAINTAINERS: Remove arm-coff and arm-pe from target list.

If I read this right, the whole coff_make_msymbol_special can be
zapped. There is also some more perplexing coff stuff in arm-tdep.c,
that could go too, I believe.

> >> Consequently, I'd like to propose that "info" be superseeded by a
> >> "struct bfd_symbol *" pointer.
> >
> >

> [...]
> If I ignore coff, Arm's arm_pc_is_thumb would look like:
>
> sym = lookup_minimal_symbol_by_pc (memaddr);
> if (sym && sym->bfd_symbol is "elf like")
> return (ELF_ST_TYPE (((elf_symbol_type *)
> (sym->bfd_symbol))->internal_elf_sym.st_info) == STT_LOPROC)
> else
> return 0;
>
> MIPS would be identical. The existing MAKE_MSYMBOL_SPECIAL wouldn't be
> needed.
>
> The other ELF use in elfread + dbxread:
>
> /* Pass symbol size field in via BFD. FIXME!!! */
> size = ((elf_symbol_type *) sym)->internal_elf_sym.st_size;
> msym = record_minimal_symbol_and_info
> ((char *) sym->name, symaddr,
> ms_type, (void *) size, sym->section, objfile);
>
> (having calls to record_minimal_symbol_and_info with a NULL info sux :-)

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

I see two:

elfread.c: msym = record_minimal_symbol_and_info
((char *) sym->name, symaddr,
ms_type, (void *) size, sym->section, objfile);

This one, together with MSYMBOL_SIZE could be changed to use bfd information.

coffread.c: msym = prim_record_minimal_symbol_and_info
(cs->c_name, tmpaddr, ms_type, (void *) (long) cs->c_sclass,
sec, NULL, objfile);

This one.... I agree with Michael, I don't see it tested by pulling it
out of a minsym. So the parameter could just be removed.

Then there is the MAKE_MSYMBOL_SPECIAL macro.

coffread.c: if (msym)
COFF_MAKE_MSYMBOL_SPECIAL (cs->c_sclass, msym);
This one goes with arm-coff, which is dead.

elfread.c: ELF_MAKE_MSYMBOL_SPECIAL (sym, msym);
this one goes with arm, sh64, mips, m68hc11.

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

So, ok. Makes sense.

elena