From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4586 invoked by alias); 29 Nov 2011 08:41:59 -0000 Received: (qmail 4490 invoked by uid 22791); 29 Nov 2011 08:41:58 -0000 X-SWARE-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,BAYES_00,KAM_STOCKTIP,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.154) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Nov 2011 08:41:37 +0000 Received: from md1.u-strasbg.fr (md1.u-strasbg.fr [IPv6:2001:660:2402::186]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id pAT8f7VV058971 ; Tue, 29 Nov 2011 09:41:07 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms8.u-strasbg.fr [130.79.204.17]) by md1.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id pAT8f4vR033083 ; Tue, 29 Nov 2011 09:41:05 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id pAT8f3F4069229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) ; Tue, 29 Nov 2011 09:41:03 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Joel Brobecker'" , "'Tom Tromey'" Cc: References: <20111123163917.GA13809@adacore.com> <20111123232406.GQ13809@adacore.com> <20111124105603.GA91879@adacore.com> <20111124163304.GR13809@adacore.com> <20111129030637.GM24943@adacore.com> In-Reply-To: <20111129030637.GM24943@adacore.com> Subject: RE: partial-symtab symbol sorting (was: "Re: GDB 7.4 branching status? (2011-11-23)") Date: Tue, 29 Nov 2011 08:41:00 -0000 Message-ID: <003201ccae72$a09cd800$e1d68800$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: 2011-11/txt/msg00807.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Joel Brobecker > Envoy=E9=A0: mardi 29 novembre 2011 04:07 > =C0=A0: Tom Tromey > Cc=A0: gdb-patches@sources.redhat.com > Objet=A0: partial-symtab symbol sorting (was: "Re: GDB 7.4 branching stat= us? > (2011-11-23)") >=20 > This is an issue that is only tangential to this patch, and should > not be considered part of the series. >=20 > I just realized that partial symbols are sorted using strcmp_iw_ordered. > This works great for C++, for instance, but only works OK for Ada. > I think that this is related to the fact that we might be using > the linkage name, rather than the natural name (we compute the natural > name only on-demand, due to memory pressure in large apps). As a result, > the strcmp_iw_ordered routine can return non-zero for two names that > ada-lang.c:compare_names would consider equal. >=20 > For instance: `pck__hello' and `pck__hello__2'. >=20 > So when doing a symbol lookup for pck__hello, for instance, we pass > our own comparison routine, which is "compatible" with > strcmp_iw_ordered to the psymtab map_matching_symbols routine. > This allows us to perform a binary search rather than linear one. >=20 > I am wondering if we shouldn't be sorting the partial symbols > using a language-specific sorting routine instead.=20=20 Did you think about what would happen to executables containing objects compiled in different languages, each having a different sorting routine? I don't understand how this would work in such a case? Pierre Muller GDB pascal language support maintainer