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

[Elena Zannoni <ezannoni at redhat dot com>]

Michael Elizabeth Chastain writes:
 > eza> OK, so what you are really saying is that there are in the whole gdb
 > eza> only a few calls to {prim_}record_minimal_symbol_and_info which have
 > eza> a non-null info parameter (the 4th one).
 > 
 > Yes, that is true.
 > 
 > I think there are two things we could do to elfread.c:
 > 
 > (1A) Quit abusing msymbol.info to store a size in some of the bits.
 >      Just create msymbol.size with the proper data type.
 > 
 > (1B) More like Elena says (and maybe Andrew is saying), change
 >      the actual algorithm to use bfd information.

this one. However I am now not so sure that we can get rid of the arm-coff
stuff. 

 > 
 > Perhaps (1A) would be a useful patch to separate out this issue
 > from the other uses of msymbol.info.  We could do (1B) later.
 > Or just go straight to (1B).
 > 
 > Over in coffread.c, with the "cs->c_sclass" being stuffed into
 > msymbol.info, gdb 4.17 (!) used to read it back.  But then that
 > changed with gdb 4.18.  Again there are two ways to deal with this:
 > 
 > (2A) Data is being written and never read back anywhere, just
 >      mechanically kill the write.
 > 

I would like to do this. I found the original change diff and
reconstructed the genesys of this no-op.

Initially there was no info field (i.e. c_sclass) passed in to
print_record_blah in coffread.c.

Then a change was made to pass that in, and read it back in arm-tdep.c
to use the storage class to determine if a symbol was thumb.

Then another change was made, to not use the info field to read the
storage class, but instead the storage class was passed directly in via
COFF_MAKE_MSYMBOL_SPECIAL(sclass, msym) (Yuck).

Here is the relevant diff, that makes me think that eliminating the
parameter to prin_record_blah in coffread.c is OK:


--- arm-tdep.c	1 Apr 1998 05:46:35 -0000	1.19
+++ arm-tdep.c	1 Sep 1998 16:24:19 -0000	1.20
@@ -68,17 +68,11 @@ arm_pc_is_thumb (memaddr)
   if (IS_THUMB_ADDR (memaddr))
     return 1;
 
-  /* The storage class for minimal symbols is stored by coffread.c in
-     the info field.  Use this to decide if the function is Thumb or Arm.  */
+  /* Thumb function have a "special" bit set in minimal symbols */
   sym = lookup_minimal_symbol_by_pc (memaddr);
   if (sym)
     {
-      unsigned sclass = (unsigned) MSYMBOL_INFO (sym);	/* get storage class */
-      return (   sclass == C_THUMBEXT
-	      || sclass == C_THUMBSTAT
-	      || sclass == C_THUMBEXTFUNC
-	      || sclass == C_THUMBSTATFUNC
-	      || sclass == C_THUMBLABEL);
+      return (MSYMBOL_IS_SPECIAL(sym));
     }
   else
     return 0;
@@ -1528,4 +1525,15 @@ _initialize_arm_tdep ()
 				  "Set usage of ARM 32-bit mode.\n", &setlist),
 		     & showlist);
 
+}
+
+/* Test whether the coff symbol specific value corresponds to a Thumb function */
+int
+coff_sym_is_thumb(int val)
+{
+	return (val == C_THUMBEXT ||
+      val == C_THUMBSTAT ||
+      val == C_THUMBEXTFUNC ||
+      val == C_THUMBSTATFUNC ||
+      val == C_THUMBLABEL);
 }


This was an incomplete cleanup, basically.

I'll send a patch. Maybe it will help understanding what to do with the rest.

elena


 > (2B) Data is being written and never read back anywhere, investigate
 >      what *should* be happening (if anything).  And it might turn out
 >      that what *should* happen is the same code should die, after
 >      someone puts some thought into it.
 > 
 > I have to say, I was a fan of (2A), but now I am not, because if
 > we just do (2A), then we have nothing to remind us of (2B) later.
 > 
 > eza> Then there are MSYMBOL_IS_SPECIAL, msymbol_is_special, MSYMBOL_IS_RTC,
 > eza> MSYMBOL_IS_RTI. All of them can just use the bfd symbol instead, and
 > eza> are only in the tdep files.
 > 
 > Yeah.
 > 
 > eza> So, ok. Makes sense.
 > 
 > Sounds like everybody is converging on a common vision.  Yay.
 > 
 > Michael C