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

Elena Zannoni
2003-10-14T20:09:06Z

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