From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14240 invoked by alias); 17 Apr 2012 14:16:26 -0000 Received: (qmail 14225 invoked by uid 22791); 17 Apr 2012 14:16:25 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,TW_BJ,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 17 Apr 2012 14:16:10 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3HEFuic011135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Apr 2012 10:15:57 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q3HEFsop024625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 17 Apr 2012 10:15:55 -0400 From: Tom Tromey To: Pedro Alves Cc: Joel Brobecker , gdb-patches@sourceware.org Subject: Re: RFC: bfd_section should not be NULL in call to prim_record_minimal_* References: <1334610821-10974-1-git-send-email-brobecker@adacore.com> <4F8D5EEC.30908@redhat.com> Date: Tue, 17 Apr 2012 14:21:00 -0000 In-Reply-To: <4F8D5EEC.30908@redhat.com> (Pedro Alves's message of "Tue, 17 Apr 2012 13:15:40 +0100") Message-ID: <87hawiwijp.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00474.txt.bz2 >>>>> "Pedro" == Pedro Alves writes: Pedro> [In my mind, symbols ideally wouldn't need back pointers to thei Pedro> "containers" (symtabs, object files, etc), because that wastes Pedro> space; the lookup routines instead should bubble up the "container" Pedro> the symbol was found in if necessary. But that may be very Pedro> hard to do.] I agree, both that this would be preferable and that it might be hard. In fact, on my current "split objfile" branch (archer-tromey-multi-inferior-3), I had to break this link -- on the branch, the symbols are not relocated and may be shared by multiple objfiles. (I sent a WIP version of this branch to gdb-patches a while ago.) I broke the linkage in a somewhat hacky way, though. The branch is big enough that I didn't want to also try to fix this problem at the same time. Pedro> The "section" and "obj_section" are one of those sources of difference Pedro> and confusion that it'd be nice to get rid of: No kidding. I have often wondered about this myself. Pedro> OTOH, this stuff is space sensitive, and in the long term, Pedro> it could prove better to only hold a "short" instead of a Pedro> pointer (8 bytes on 64-bit hosts). It seems like we could perhaps use the BFD index everywhere. This gets into a fair amount of ugly business. Pedro> Like in the patch below. When testing it, I ran linespec.exp Pedro> first, and that revealed that msymbol_objfile had a bug in that Pedro> it didn't look at all the pspaces, only the current (the test Pedro> adds a second inferior, therefore a second pspace). Not good Pedro> when you want to look up the objfile because you want to know the Pedro> msyms' pspace to begin with. This seems odd to me. And, with the split objfile stuff, it would be actively wrong, since a given msymbol could appear in multiple pspaces. Now, normally I wouldn't mention a patch that isn't checked in yet, but... I think it would be better to pass the pspace around with the minimal symbol in linespec.c. We certainly know it at the time we actually find the minsym, so it is just a matter of not losing the information. Ok, I just looked at linespec.c again, and this is why there is an objfile in minsym_and_objfile. Here's a totally untested patch based on this idea. Note that compare_msymbols, while not exactly wrong right now, is definitely weird in that it makes an assumption about the layout of minsym_and_objfile. Tom diff --git a/gdb/linespec.c b/gdb/linespec.c index 228214b..7cbf1bf 100644 --- a/gdb/linespec.c +++ b/gdb/linespec.c @@ -1899,7 +1899,7 @@ convert_linespec_to_sals (struct linespec_state *state, linespec_p ls) VEC_iterate (minsym_and_objfile_d, ls->minimal_symbols, i, elem); ++i) { - pspace = SYMBOL_OBJ_SECTION (elem->minsym)->objfile->pspace; + pspace = elem->objfile->pspace; set_current_program_space (pspace); minsym_found (state, elem->objfile, elem->minsym, &sals); } @@ -2584,20 +2584,20 @@ compare_symbols (const void *a, const void *b) static int compare_msymbols (const void *a, const void *b) { - struct minimal_symbol * const *sa = a; - struct minimal_symbol * const *sb = b; + const struct minsym_and_objfile *sa = a; + const struct minsym_and_objfile *sb = b; uintptr_t uia, uib; - uia = (uintptr_t) SYMBOL_OBJ_SECTION (*sa)->objfile->pspace; - uib = (uintptr_t) SYMBOL_OBJ_SECTION (*sb)->objfile->pspace; + uia = (uintptr_t) sa->objfile->pspace; + uib = (uintptr_t) sa->objfile->pspace; if (uia < uib) return -1; if (uia > uib) return 1; - uia = (uintptr_t) *sa; - uib = (uintptr_t) *sb; + uia = (uintptr_t) sa->minsym; + uib = (uintptr_t) sb->minsym; if (uia < uib) return -1;