From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19695 invoked by alias); 20 Jan 2004 13:23:57 -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 19547 invoked from network); 20 Jan 2004 13:23:55 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 20 Jan 2004 13:23:55 -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 i0KDNsl23066; Tue, 20 Jan 2004 08:23:54 -0500 Received: from pobox.surrey.redhat.com (pobox.surrey.redhat.com [172.16.10.17]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i0KDNra31621; Tue, 20 Jan 2004 08:23:53 -0500 Received: from localhost.localdomain.redhat.com (vpnuser4.surrey.redhat.com [172.16.9.4]) by pobox.surrey.redhat.com (8.12.8/8.12.8) with ESMTP id i0KDNnhM001773; Tue, 20 Jan 2004 13:23:50 GMT To: Richard.Earnshaw@arm.com Cc: gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: RFA: Skip ARM ELF Mapping symbols when showing disassembly References: <200311131445.hADEj7C19503@pc960.cambridge.arm.com> <20040114234206.GA7504@nevyn.them.org> From: Nick Clifton Date: Tue, 20 Jan 2004 13:23:00 -0000 In-Reply-To: <20040114234206.GA7504@nevyn.them.org> (Daniel Jacobowitz's message of "Wed, 14 Jan 2004 18:42:06 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-01/txt/msg00554.txt.bz2 Hi Guys, > Daniel Jacobowitz writes: >> I wonder whether a better way to handle all this is to override >> slurp_symbol_table for arm-elf to a routine that just skips the mapping >> symbols entirely (or at least, doesn't put them into the list that it >> passes back to its caller), then to add a separate function to slurp the >> mapping symbols independently. Then gdb and the disassembler (and the >> linker error reports) would all just work normally. >> >> It would be necessary to add support for copying and fixing up the mapping >> symbols when linking, but that's probably not too hard. > > Actually, I think it's not necessary, since elf_link_input_bfd doesn't > use the slurp routines anyway - it parses the ELF symbol table > directly. In testing it appears to work. > > There is another problem, though. The symbols are in the symbol table > and thus have assigned numbers. The returned list of symbols is passed > back to functions like bfd_canonicalize_reloc, which use the list of > symbols to resolve relocations. Probably other consumers assume the > whole list of ELF symbols is returned, also, and index it by other > copies of the symbol index. So the linker doesn't appear to care, but > objdump and possibly GDB do. > > Any ideas on how to resolve this? We can't NULL out the mapping > symbols in symptrs either, because the list is defined to be > NULL-terminated (even though we return its length...). How about providing a new BFD function which allows the caller to determine if a symbol should be ignored ? This function would call through to an architecture specific backend routine if necessary, although a generic routine which never ignored any symbols would be the default. We might even generalise the function to take a third argument (apart from the bfd and the symbol) which is a bit-field defining the proposed purpose(s) for the symbol and then have the function determine if it is suitable. ie something like this: enum { not_suitable; partially_suitable; fully_suitable } bfd_suitability; #define bfd_purpose_display (1 << 0) /* Should the symbol be shown to the user ? */ #define bfd_purpose_resolve (1 << 1) /* Should the symbol be used for resolving relocs ? */ extern bfd_suitability bfd_symbol_suits_purpose (bfd * the_bfd, bfd_symbol * the_symbol, unsigned the_purposes); Cheers Nick