From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53129 invoked by alias); 16 Jun 2015 21:02:46 -0000 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 Received: (qmail 53114 invoked by uid 89); 16 Jun 2015 21:02:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f44.google.com Received: from mail-oi0-f44.google.com (HELO mail-oi0-f44.google.com) (209.85.218.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 16 Jun 2015 21:02:43 +0000 Received: by oiyy130 with SMTP id y130so3547389oiy.0 for ; Tue, 16 Jun 2015 14:02:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZVHgECiK/Ax3qrr+DVUSWtl6wvmIU+x3d38sK6xUGpQ=; b=SkqoscmNKpAEH2xrr5BIdWLmzkapuTfMSMrfuuGpeN/bBaGtKDK30DZU5RttTu4jIU qUDEy29A5fwm8AHiNBGXRtChxOufNR1KFxNkWFKq4i3m1yOiMUmlY0UCJXPjUE9am5s6 Pb3v/As/9070TsM+km34cDHZol99VS3P50dmif0zDpfr90eYi/zpAKXWSaC98W8hu153 8PJsS/h+9T46uxxk3RyBFgGndonG+1pBfXKIS+YJeM2IyuMjMqKf4IQH0xOTpYYD8epM jgvY2PI+LtN34qBDeELZg/ZsJPbszvTibGXjt/47o9h8uP2Wd+tvZZyhqTueOnrKNbIh R7Kg== X-Gm-Message-State: ALoCoQnHU79tWiVLBsQ8iHFujOqtBquUrrSRrrqhVyaFKuwLWBdg6STYPSI+fyJ9dglpAiDXEOUC MIME-Version: 1.0 X-Received: by 10.182.118.163 with SMTP id kn3mr1855203obb.80.1434488561474; Tue, 16 Jun 2015 14:02:41 -0700 (PDT) Received: by 10.182.89.99 with HTTP; Tue, 16 Jun 2015 14:02:41 -0700 (PDT) In-Reply-To: <001a1135a192a92e3f0518a643d3@google.com> References: <001a1135a192a92e3f0518a643d3@google.com> Date: Tue, 16 Jun 2015 21:02:00 -0000 Message-ID: Subject: Re: [RFC] Revisit PR 16253 ("Attempt to use a type name...") From: Doug Evans To: Keith Seitz Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00353.txt.bz2 On Tue, Jun 16, 2015 at 12:54 PM, Doug Evans wrote: >... > btw, > > I think I have a simple way to get the perf back with the original > patch, but it involves (I think, TBD) "breaking" > psyms/gold-generated-gdb-index the same way gdb-generated-gdb-index > is "broken": PR 17387. > Namely, only record one static psym, the theory being > if one is not in a context where static symbol my_foo is defined, > gdb is going to (essentially) pick a random one so why record them all? > The catch is that, e.g., "info types foo" uses psyms/gdb-index too > so if we went this route we'd either have to accept the breakage > that .gdb_index introduced (PR 17387) or rewrite "info types, etc., > to work differently: it'd have to scan the debug info, but how important > is a fast "info types"? One could employ various kinds of caching > to speed things up a bit. Sorry for the followup. Another way would be to have two different kinds of lookup. IOW, record all the static versions of a symbol in the index, but (1) only use one of them (the first?) for some lookups and (2) use all of them for "info types"-like lookups. It's still substandard, I think, as the symbol we use for (1) may have the wrong domain, and we should really just fix gdb-generated-gdb-index for 17387, and record the domain in the index to fix the perf issue. OTOH, as with your v2 patch for 16253, it's an incremental approach.