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

[Elena Zannoni <ezannoni@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