From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31406 invoked by alias); 11 Oct 2003 20:02:38 -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 31399 invoked from network); 11 Oct 2003 20:02:37 -0000 Received: from unknown (HELO localhost.redhat.com) (65.49.0.121) by sources.redhat.com with SMTP; 11 Oct 2003 20:02:37 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 3876D2B89; Sat, 11 Oct 2003 16:02:30 -0400 (EDT) Message-ID: <3F8861D6.7080302@redhat.com> Date: Sat, 11 Oct 2003 20:02: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: Michael Elizabeth Chastain Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] Deprecate msymbol.info, add msymbol.bfd_symbol? References: <200310111839.h9BIdNm8020908@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00411.txt.bz2 > 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. The third meaning needs to be refined slightly. MAKE_MSYMBOL_SPECIAL, for coff, doesn't yet take a "bfd_symbol", in fact, coffread doesn't even use BFD's canonicalize_symtab to read the symbols. >> 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? If I ignore coff, Arm's arm_pc_is_thumb would look like: sym = lookup_minimal_symbol_by_pc (memaddr); if (sym && sym->bfd_symbol is "elf like") return (ELF_ST_TYPE (((elf_symbol_type *) (sym->bfd_symbol))->internal_elf_sym.st_info) == STT_LOPROC) else return 0; MIPS would be identical. The existing MAKE_MSYMBOL_SPECIAL wouldn't be needed. The other ELF use in elfread + dbxread: /* Pass symbol size field in via BFD. FIXME!!! */ size = ((elf_symbol_type *) sym)->internal_elf_sym.st_size; msym = record_minimal_symbol_and_info ((char *) sym->name, symaddr, ms_type, (void *) size, sym->section, objfile); (having calls to record_minimal_symbol_and_info with a NULL info sux :-) could be addressed similar. Anyone realise that the code assumes elf? >> 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. Yes, I was secretly assuming that. > 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. This could immediatly eliminate two of them. I think the coff version of ARM could also be eliminated if coffread (yea, right ... :-) fully utilized BFD. Andrew