From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11920 invoked by alias); 14 Oct 2003 20:09:06 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 11911 invoked from network); 14 Oct 2003 20:09:04 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 14 Oct 2003 20:09:04 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9EK94M08608 for ; Tue, 14 Oct 2003 16:09:04 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9EK93r19645 for ; Tue, 14 Oct 2003 16:09:03 -0400 Received: from localhost.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h9EK92wC009862; Tue, 14 Oct 2003 16:09:03 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 56AAE2CE25; Tue, 14 Oct 2003 16:20:17 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16268.23169.221754.123812@localhost.redhat.com> Date: Tue, 14 Oct 2003 20:09:00 -0000 To: Michael Elizabeth Chastain Cc: ac131313@redhat.com, ezannoni@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol? In-Reply-To: <200310141736.h9EHal5r000665@duracef.shout.net> References: <200310141736.h9EHal5r000665@duracef.shout.net> X-SW-Source: 2003-10/txt/msg00470.txt.bz2 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