From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 944 invoked by alias); 11 Oct 2003 18:39:25 -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 903 invoked from network); 11 Oct 2003 18:39:24 -0000 Received: from unknown (HELO concert.shout.net) (204.253.184.25) by sources.redhat.com with SMTP; 11 Oct 2003 18:39:24 -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 h9BIdNqs007660; Sat, 11 Oct 2003 13:39:23 -0500 Received: from duracef.shout.net (localhost [127.0.0.1]) by duracef.shout.net (8.12.10/8.12.9) with ESMTP id h9BIdNVd020909; Sat, 11 Oct 2003 13:39:23 -0500 Received: (from mec@localhost) by duracef.shout.net (8.12.10/8.12.9/Submit) id h9BIdNm8020908; Sat, 11 Oct 2003 14:39:23 -0400 Date: Sat, 11 Oct 2003 18:39:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200310111839.h9BIdNm8020908@duracef.shout.net> To: ac131313@redhat.com, gdb-patches@sources.redhat.com Subject: Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol? X-SW-Source: 2003-10/txt/msg00409.txt.bz2 First, ignore the comment in struct minimal_symbol, the comment is wrong and obsolete. 'msymbol.info' currently has three meanings. The first meaning is: coffread.c stores a 'storage class' into msymbol.info. However, no code *ever* reads that back. gdb 4.17 used to read this information in arm_pc_is_thumb to decide whether an msym was a Thumb symbol or Arm symbol. But this mechanism was replaced in gdb 4.18 with COFF_MAKE_MSYMBOL_SPECIAL. The first meaning can die as soon as someone can test a coff platform with a trivial patch to coffread.c. The second meaning is: dbxread.c stores the size of the msym in 'msymbol.info'. It does this in case SOFUN_ADDRESS_MAYBE_MISSING is set, in order to synthesize texthigh for that file. The third meaning is that arm-tdep.c, m68hc11-tdep.c, mips-tdep.c, and sh-tdep.c use msymbol.info as a place to store one or two flag bits. > Consequently, I'd like to propose that "info" be superseeded by a > "struct bfd_symbol *" pointer. I don't quite understand your proposal, because there are three meanings of "msymbol.info". Which meanings do you want to supersede? Can you put up a little sample code? > The consequence will be that, for a time, the minimal symbol table will > be bigger. Here are some numbers from some old test run: msym 0.3 mb psym 11.9 mb sym 30.1 mb mt 8.7 mb # main_type The msym's are not space critical. It sucks that msymbol.info is overloaded for three different meanings (and none of them is a pointer so we get all those nasty casts). Let's separate it into different fields, and then when the data types are nice and correct, if we want the space back (which I think we won't), then we can go for 'union' and bit-field things to get the size back down. Andrew, I think what you are saying is that you want to separate out the data field for meaning #3, and have a separate field in the minsym. And your new field would be a "struct bfd_symbol *" pointer instead of the current 1-2 flag bits. That would be fine with me. Michael C