From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30451 invoked by alias); 21 Nov 2014 17:34:04 -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 30440 invoked by uid 89); 21 Nov 2014 17:34:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-vc0-f171.google.com Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 21 Nov 2014 17:34:02 +0000 Received: by mail-vc0-f171.google.com with SMTP id hy4so517722vcb.2 for ; Fri, 21 Nov 2014 09:33:59 -0800 (PST) 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=wA1AhWIdbB39sjZ99yxfaDsHnqhpn0g2bYF8mEdXQ4o=; b=csaZlqr7o5VT3rLqqw4WRKWXkRExeZAr6IRbE6INTisC8mUk/WmCdDsjeWlI5SdZ8z IxiUUhXzu2l635wHCTYRg9UNoRqIWE8Vd8egTVcHxfM3nSSt9CCnyWJs/vs+/5WxuckK CVrzLdnSzj8Kr8jqeiCPYdLIqeUmgiF3naZnDXnqCTqR+xJNVGq65WmGrGFGePfGOF9U ooqKe4s8k7kepgfJN5OSa/ccYD8R41BRq7AEQLOYSUCx/lo8fMQ6opi2AE++GMs9RRlq 8KlBT+Aow6vhmAKmi70SL8A7IfTmK0ESGVJawGO/54VsuJZgxjyMMo9gLZRBqB3fj33I FD+Q== X-Gm-Message-State: ALoCoQmGEe5M9lXUa9ndAaYr6acTEjNw9Y2/LPMEJlR/8JWX4YK2xllS3xMLzpmIAW8JVPPHu72M MIME-Version: 1.0 X-Received: by 10.52.227.234 with SMTP id sd10mr5126429vdc.28.1416591239163; Fri, 21 Nov 2014 09:33:59 -0800 (PST) Received: by 10.52.114.101 with HTTP; Fri, 21 Nov 2014 09:33:59 -0800 (PST) In-Reply-To: <837fyp57bu.fsf@gnu.org> References: <837fyp57bu.fsf@gnu.org> Date: Fri, 21 Nov 2014 17:34:00 -0000 Message-ID: Subject: Re: [PATCH 2/4] python support for fetching separate debug files: have_debug_info From: Doug Evans To: Eli Zaretskii Cc: gdb-patches , Pedro Alves , Sergio Durigan Junior Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00522.txt.bz2 On Thu, Nov 20, 2014 at 11:41 PM, Eli Zaretskii wrote: >> From: Doug Evans >> Date: Thu, 20 Nov 2014 13:22:39 -0800 >> >> This patch provides an API call to determine whether debug information >> is present. It's based on the same test that gdb internally uses >> to decide whether to look for separate debug files. > > OK for the documentation parts. > > Btw, I wonder why this is useful, given this caveat: > >> +Note that a program compiled without @samp{-g} may still have some debug >> +information, e.g., from the @code{C} runtime. Thus a value of @code{True} >> +for this attribute does not mean that debug information is present for >> +every source file in the program. It only means that debug information >> +is present for at least one source file. > > If this attribute cannot be relied upon, why is it a good idea to > expose it to Python? It's a good question. I thought about the name for this attribute for a non-insignificant amount of time. The problem that needs to be solved is for Python code to be able to tell whether to spend time fetching separate debug files, as the latter can take a significant amount of time. Also, a program may use a large number of shared libraries and the user may wish (or not wish) debug info to be fetched for each one. So we want, IMO, a simple and cheap initial test for whether we need to fetch debug files. For the use-case in question, another way to look at the attribute is "Has debug info been stripped or not?". Thus one thought I had was naming it "is_stripped_debug". The goal being to better specify the intent. But it still has the same problem: even if a binary didn't have debug info stripped that doesn't mean that the desired pieces of it were compiled with -g. Thus I went with have_debug_info. [has_debug_info?] I got to the point of not wanting to over-think this. It turns out that in practice, for the use case in which this attribute will be put, the answer it gives works well enough. Plus providing the ability to be consistent with what gdb itself does has value: being inconsistent can lead to confusion. I can imagine some use-cases wanting more intelligent tests for determining whether to put in the effort to fetch a separate debug file (e.g., is debug info for a particular class present). Going this route is up to the implementer of the Python code. What we're providing here is just building blocks.