From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7710 invoked by alias); 11 Oct 2003 17:16:12 -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 7703 invoked from network); 11 Oct 2003 17:16:11 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 11 Oct 2003 17:16:11 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 7664C2B89 for ; Sat, 11 Oct 2003 13:15:41 -0400 (EDT) Message-ID: <3F883ABD.3080504@redhat.com> Date: Sat, 11 Oct 2003 17:16:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb-patches@sources.redhat.com Subject: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00405.txt.bz2 There isn't yet a patch yet. I wan't to run the theory past people, especially the symtab maintainers. A recent thread discussed the "info" field of the symbol table where MichaelC was trying to pack it down, while I was arguing that it should "just go", instead have the computation performed by MAKE_MSYMBOL_SPECIAL on every minimal-symbol performed on-demand (and after the symbo-table load). The problem with eliminating "info" is that it would leave the on-demand code with no efficient way to find the underlying BFD info that it needes :-( Consequently, I'd like to propose that "info" be superseeded by a "struct bfd_symbol *" pointer. I say "superseed" as I'd prefer doing this in two steps. In addition to the per-architecture MAKE_MSYMBOL_SPECIAL, readers like elfread.c also squirrel away info in that field :-/ The consequence will be that, for a time, the minimal symbol table will be bigger. Since its the minimal-symbol table I don't feel too guilty, long term the minimal-symbol's size will be restored. In fact, given the apparent overlap between bfd_symbol and general_symbol_info (name, section, bfd_section, ?), it opens the way to further savings. thoughts? does the theory look correct? Andrew