From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10983 invoked by alias); 14 Oct 2003 17:36:50 -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 10976 invoked from network); 14 Oct 2003 17:36:49 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 14 Oct 2003 17:36:49 -0000 Received: from duracef.shout.net (duracef.shout.net [204.253.184.12]) by concert.shout.net (8.12.10/8.12.10) with ESMTP id h9EHal4X012504; Tue, 14 Oct 2003 12:36:47 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.10/8.12.9) with ESMTP id h9EHalfa000666; Tue, 14 Oct 2003 12:36:47 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.10/8.12.9/Submit) id h9EHal5r000665; Tue, 14 Oct 2003 13:36:47 -0400 Date: Tue, 14 Oct 2003 17:36:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200310141736.h9EHal5r000665@duracef.shout.net> To: ac131313@redhat.com, ezannoni@redhat.com Subject: Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol? Cc: gdb-patches@sources.redhat.com X-SW-Source: 2003-10/txt/msg00466.txt.bz2 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. 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. (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