This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol?
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Michael Elizabeth Chastain <mec at shout dot net>, gdb-patches at sources dot redhat dot com
- Date: Mon, 13 Oct 2003 16:39:45 -0400
- Subject: Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol?
- References: <200310111839.h9BIdNm8020908@duracef.shout.net><3F8861D6.7080302@redhat.com>
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